I'm trying to debug Erlang node started on remote PC, from my local PC.
For debugging I'm using latest IntelliJ Idea with Erlang plugin.
Remote node started like this:
erl -pa /path/to/myapp/ebin -name myapp#myremote.host -setcookie mycookie -shell -eval "application:start(myapp)."
Idea uses Rebar "Erlang Remote Node" configuration , so local node started and connected to myapp#myremote.host.
I can confirm connection, because "nodes()." on remote shell show my connected node from local machine. Also net_adm ping/pong works.
"epmd -names" also show correspond sessions.
Unfortunately all my breakpoints within IDE not triggering, so I can't stop execution and perform step-by-step debugging via IDE.
Meantime such debug session works like a charm in case of both nodes started on local PC.
Please suggest me what I'm doing wrong. Many thanks in advance .
PS: I'm also tried with short node names, with same result.
You should setup epmd for listening on external IP (http://erlang.org/doc/man/epmd.html) and after that DNS name "myremote.host" should be resolve to it IP
Related
Original Post
I have a Windows workstation with WSL2 and Docker installed that I am able to use for container based development in VS Code. I would like to be able to develop inside the containers on this system remotely. I am able to SSH directly into the WSL2 environment on the workstation and am able to start the docker daemon without logging directly into Windows by creating a Task to start the daemon automatically as described here: https://stackoverflow.com/a/59467740/10692741
However when I try to access Docker on the remote machine by following this guide: https://code.visualstudio.com/docs/remote/containers-advanced#_developing-inside-a-container-on-a-remote-docker-host, I get the following error:
error during connect: Get http://docker/v1.24/version: net/http: HTTP/1.x transport connection broken: malformed HTTP status code "\x00c\x00o\x00m\x00m\x00a\x00n\x00d\x00"
I have also tried connecting via a SSH tunnel as outlined here: https://code.visualstudio.com/docs/remote/troubleshooting#_using-an-ssh-tunnel-to-connect-to-a-remote-docker-host and am unable to connect to Docker as well.
Has anyone had success with a setup like this? Or is this not supported due to limitations with Docker on Windows, WSL2, and/or Windows OpenSSH implementation?
Update: 2021-01-21
When I SSH into the Windows machine remotely, I am able to see the docker containers in the VS Code extension. I am able to start them, stop them, and enter into them with the shell. However, when I try to attach VS Code I get same error shown above.
Things that may have possibly affected this over the past couple days:
Adding SSH keys on my local machine to the ssh-agent via ssh-add /my/key
Exposing Docker daemon on tcp://localhost:2375 without TLS on the remote Windows machine
Also I want to note that the I've tried using Windows, Mac, and Linux as the local machine. With Mac and Linux I am able to open a remote session into the Windows machine, but from the Windows local machine I am able to SSH into the remote Windows machine but cannot open a remote connection in VS Code for some reason.
Ok, I was able to get this working using the port/socket forwarding technique. For sake of clarity, I'll use:
local development workstation, local workstation, or just workstation to indicate the computer from which we wish to use VSCode to access Docker containers on ...
the remote Docker host, remote, or just Docker host
Sanity check -- Do you have Docker Desktop installed on both systems? On the local development workstation, you can skip the WSL2 integration, but you'll at least need the client tools, since the VSCode extension uses them.
Steps I took:
I already had Docker with WSL2 integration set up on my main system (which for the purposes of this exercise, became my remote Docker host), along with VSCode, so I knew everything was working there. It sounds like that was your starting point as well.
On another system on the same network (accessed with RDP to make it simple), I already had VSCode installed as well, with the Remote Development Extension Pack. I also have WSL on that system, but only a v1 instance there. Not that WSL on the workstation should be a factor at all for the purposes of this exercise.
I installed Docker Desktop for Windows on that local development workstation.
I also installed the Docker extension for VSCode, since I didn't yet have it on the local development workstation.
On the workstation, I was not yet set up to SSH from PowerShell into my WSL Ubuntu distro on the remote. From PowerShell on the workstation, I generated an ECDSA key (per this and other documents) and added the public key to my authorized_keys on the the remote.
On the workstation, I started the OpenSSH Authentication Service and added the newly created key to the agent (in PowerShell) with ssh-agent add ~\.ssh\id_ecdsa.
I logged out of the workstation and back in so that the path changes were picked up for the Docker desktop install.
I was then able to ssh from Powershell on the local to Ubuntu/WSL on the remote with the port forwarding. Since I'm using the Windows 10 OpenSSH server as a jumphost to my WSL SSH servers, my command looked slightly different (with a -o "ProxyCommand ... mainly), but overall the structure is the same as the one listed in the "SSH Tunnel" doc you linked in your question.
On the remote (manually, not through any integration from the local), I did a basic docker run -it --rm Ubuntu and left it open.
On the local, from PowerShell, I set the DOCKER_HOST environment variable via [System.Environment]::SetEnvironmentVariable("DOCKER_HOST","tcp://localhost:23750").
I was then able to see the remote container using docker ps on the local. I could also docker exec -it containername bash into it remotely.
Of course, the above two steps aren't needed in the long term for VSCode, they were just part of my process to make sure everything was up and running (since, as you might expect, I did have several points at which I failed during this process).
So with that working, it was a simple matter in VSCode to change the Docker extension's DOCKER_HOST setting to tcp://localhost:23750. And voila, I could see all images on the remote as well as attach to them from VSCode.
Other thing(s) to check
I'll add to this list if we find additional reasons why it might not be working, but for now:
You mention that you are starting the Docker Desktop daemon automatically at startup via Task Manager, but you don't mention anything about the WSL2 instance. However, since you are able to ssh into it, I assume you have a way to bring it up as well? My experience has been that, unless the owning user is logged in, WSL terminates any instances after a few seconds, even if a service is running. There's a workaround, I believe, that I can dust off if this is a problem.
Running into the subject issue trying to update the proxies with nswag... funny enough, the app that this came with is preconfigured to use a specific port for that service, but I don't see anything on that port using netstat -ano in the command line. Does anyone have any thoughts?
Before running nswag/refresh.bat the host needs to be up and running.
To start host, copy the below lines and create a batch file (bat).
CD "D:\Github\MySolution\src\MyProject.Web.Host"
SET ASPNETCORE_ENVIRONMENT=Development
SET ASPNETCORE_URLS=http://*:22742
dotnet run
It was some settings on the server (so a corporate guy told me), so nothing on my end, but thank you everyone for your help!
I am trying to run JMeter Webdriver samplers in IE on a remote machine. I have changed remote_hosts to the IP address of the remote machine. JMeter server on the remote machine is also started. When I run the tests from the JMeter GUI on the local machine (Run->Remote Start menu) I can see the command line window in remote machine showing
"Started the test..."
and immediately
"Finished the test..."
So the test runs but nothing actually happens.
I must be missing some configuration.
Can someone please help?
You need to install the same Selenium/WebDriver Support plugin to the remote slave(s). This can be done either by copying the whole JMeter installation to the slave host(s) or using JMeter Plugins Manager on each slave.
You need to download Internet Explorer Driver binary and put it to the same location as on the master host.
In case of any problems check jmeter-server.log file on remote slave - normally it should contain the root cause (or clue on what is wrong)
We have a Jenkins instance running on Ubuntu that has several slaves in different systems. One of them is a Windows 7 host, having jenkins slave instance configured as a service.
We have a problem that when that machine is rebooted, master Jenkins doesn't realize it's gone. It looks to be just fine in the nodes view. Then, when a build is issued that is supposed to use that slave it gets stuck. If that is stopped, the next build fails immediately
Caused by: java.util.concurrent.TimeoutException: Ping started at 1457016721684 hasn't completed by 1457016961684
... 2 more
[EnvInject] - [ERROR] - SEVERE ERROR occurs: channel is already closed
When the slave has started up and it tries to connect back to master, connection is refused, and in the logs there is an error saying connection with that name already exists:
Server didn't accept the handshake: xxx is already connected to this master. Rejecting this connection.
There is issue JENKINS-5055 which claims a fix was committed allowing the same JNLP slave to reconnect without getting rejected, apparently this commit, and according to changelog, it was introduced in version 1.396 (2011/02/02). We are however using version 1.639 and seeing this. Somebody else seems to be seeing it as well. By looking at current codebase, I see where the error is coming from, but don't see the fix done in Jenkins-5055.
Any ideas on resolving this?
Edit: also asked on jenkins user mailing list, but no responses.
We faced the same issue. Used https://wiki.jenkins-ci.org/display/JENKINS/slave-status as workaround
Reinstalling the slave on a Windows Server 2012 R2 machine shows no signs of this behavior, so it seems that either there was a mistake done during installation steps or this is something caused by using a workstation Windows version.
Regardless, here were the steps to get it working, assuming a brand new installation of Windows, with no network connectivity, and master instance using a self-signed certificate:
Install JRE on the machine. If you have 64-bit operating system, install both 32-bit and 64-bit, otherwise go with 32-bit. Download link here
Install .NET 3.5 on the machine. This is needed by the Jenkins service. You can follow the steps outlined by my other answer for this.
Install Jenkins using Windows installer (.zipped) to C:\Jenkins. It can be downloaded from here.
Check your installation is responding by navigating to http://localhost:8080 . In case of trouble, check for logs in the jenkins folder. If there is a port conflict, edit jenkins.xml and change the httpPort to something else.
From the Windows computer, navigate to your master jenkins and configure a new node there.
Start a slave agent using Java Launch Agent in configure -> node screen (you need to be still using your Windows slave computer)
You should see a visible window opening. From there, select File -> Install as a service. (details and screenshots) If you experience an error without proper explanation, confirm .NET 3.5 is properly installed. If you see "WMI.WmiException: AccessDenied", save the jnlp file locally and start it from administrator prompt or otherwise with elevated privileges (details).
From the Administrative tools -> Services, stop and disable the Jenkins service, and stop Jenkins Slave Agent but leave it on Automatic so it will start up when starting up the computer.
This is only relevant if you're using a self-signed or otherwise problematic certificate:
download the previously mentioned Java Launch Agent file (.jnlp file) again and save it to C:\jenkins
open c:\jenkins\jenkins-slave.xml to your editor
change it to refer to your local .jnlp file by changing jnlp url parameter (file:/C:/jenkins/jenkins-slave.jnlp)
add -noCertificateCheck to parameters
replace the -secret parameter with -auth "user:pass", since otherwise automatic url get parameters will be added which will mess finding the .jnlp file
Start the Jenkins Slave Agent service again
For problems with jenkins slave service, check out jenkins-slave.err.log. For Windows Server 2012 R2, you can get the functionality of tail by using Get-Content .\jenkins-slave.err.log -Wait -Tail 10 in Powershell prompt. For older versions of Powershell, leave out -Tail 10.
Instructions for running weinre state that I need to insert following script:
<script src="http://a.b.c:8081/target/target-script-min.js"></script>
where http://a.b.c is my server IP or host name.
Couple of questions:
Does this mean that I must open port 8081 on my remote server?
Also what is the target-script-min.js? It looks like I need to upload it to a target folder?
The way you start the weinre sever is by running the command
weinre
in your command line. And then you leaving it running for as long as you're still using weinre. You have options for this command that you can find by type weinre --help, but the important ones are --boundHost, and --httpPort. --boundHost defaults to localhost and --httpPort defaults to 8080. So run
weinre --boundHost 192.168.1.2
where 192.168.3.4 is your ip address, which you can find by running ipconfig. Put the following in your code:
<script src="http://192.168.1.2:8080/target/target-script-min.js#whatever"></script>
Then, in your browser, go to
http://192.168.1.2:8080/client/#whatever
I wrote a blog post about it here: https://adam.garrett-harris.com/how-to-setup-remote-debugging-in-phonegap
To answer your second question, the target-script-min.js is just a javascript file that's a part of weinre whenever you install it. When you have weinre running, you can visit
http://192.168.1.2:8080/target/target-script-min.js
to see the file if you want.
The weinre server is "started" by executing this command weinre --boundHost a.b.c.d where a.b.c.d stands for the local IP of the desktop used for debugging. The port 8080 will be opened (default port, but you may configure an other one).
At this point, the script http://a.b.c.d:8080/target/target-script-min.js becomes available on your local network, and may be called by your application located on an other device in the same local network.
If your application or tested web page call this script, it will be seen by your desktop.
Therefore, you don't have anything to upload on your target...
Weinri debug resume
After successfully installed weinri,
1 - Run this command with your ip address:
weinre --boundHost 192.168.12.3
2 - Attach in your code header:
<script src="http://192.168.12.3:8080/target/target-script-min.js#anonymous"></script>
3 - Access your website in your tablet or whatever device
3 - Get the wenri debug screen on:
http://localhost:8080/client/#anonymous
Obs: 'anonymous' word can be replaced by another of your choice.
if you can't debug your html page even after completing all of the steps mentioned in the Nokia Developer Article,
then check your windows firewall settings.Please be sure that the firewall setting for private network is TURNED OFF ..