Fork me on GitHub
#leiningen
<
2017-09-18
>
pataprogramming17:09:46

Here’s one I haven’t run into before. I’m trying to start a REPL from the command line on OS X (10.12.6), with lein 2.7.1. It starts up fine with just lein repl but lein repl :start :host 192.168.x.x :port 9009 gives a “connection refused” message.

pataprogramming17:09:22

Not a port problem, as I can start up and connect to netcat on that IP and port.

pataprogramming17:09:52

Doesn’t work if I leave off the port, either.

bfabry17:09:18

@pataprogramming the :start option is to connect to a remote repl. is there a remote repl running on that ip and port?

pataprogramming17:09:04

@bfabry: No…isn’t that :connect, not :start? Or are the docs misleading me?

bfabry17:09:26

oh nope you're right, my bad

pataprogramming17:09:29

I’m trying to start the REPL to connect to from a VM.

pataprogramming17:09:43

So I could try :headless and see if that allows connection from another process…but I’m also wondering why it isn’t working.

pataprogramming17:09:11

Just tried the same command (:start) inside a Linux VM, with similar results. Hm.

noisesmith17:09:18

what if you give it 0.0.0.0 as a host

seancorfield17:09:31

(and @noisesmith beats me to the punch again!)

pataprogramming17:09:33

Definitely weird, if I start with :headless, I can indeed connect from another lein process using :connect.

noisesmith17:09:55

@pataprogramming it’s better to host the repl on 0.0.0.0 and use ssh with port forwarding

noisesmith17:09:11

even if it’s only running on a container - a repl is a huge root hole with no security

noisesmith17:09:33

if you bind to a visible IP it’s just asking for trouble

pataprogramming17:09:03

Do you mean 127.0.0.1? 0.0.0.0 should be all interfaces.

noisesmith17:09:15

umm… maybe I’m getting this wrong

pataprogramming17:09:43

This is an internal VMware bridge interface, so it’s not actually externally exposed.

noisesmith17:09:40

OK - yeah - 127.0.0.1 is the safe one - but I still think it’s a better practice to only host on loopback and use ssh to forward the port to another loopback on the client machine

noisesmith17:09:48

but if you know that’s safe with your vm, go for it

pataprogramming17:09:55

I should have though of port forwarding, I admit…it’s kind of a weird thing I’m trying to do. O

noisesmith17:09:17

the nice thing with port forwarding is you can use the same work flow with staging, or even prod if you need to

pataprogramming17:09:24

I do most of my dev in a Linux VM, and have been working with Overtone.

noisesmith17:09:48

oh, with overtone you’ll likely never have a staging or prod box haha

seancorfield17:09:59

I have a similar setup: host O/S is OS X and I run various O/S in Parallels Desktop. The host REPL needs to bind to an address that can be reached from the VMs. IME with OS X and Parallels, that means either 0.0.0.0 or 127.0.0.1 -- not the 192.* IP.

pataprogramming17:09:56

Overtone needs to run in the Mac context to pick up the MIDI devices, but I want to keep working in my xmonad setup (and the VM’s virtual clock messes badly with synthesis).

seancorfield17:09:31

(but I may have a different network config to you for my VMs -- I think I just let it pick the default)

noisesmith17:09:41

what about running the supercollider server on the mac and then forwarding the osc ports to the vm process?

noisesmith17:09:11

or does overtone abstract the scsynth process in a way that makes that difficult?

pataprogramming17:09:03

Heh, I wasted several commutes trying to get that working before throwing up my hands. You’re on target that Overtone is making some assumptions about scsynth.

noisesmith17:09:23

with signal processing I always prefer to default to “closer to the actual metal” (whether that means skipping virtualization, using a lower level language, eliminating “helpful” user space drivers that do annoying things like sample rate conversion…)

noisesmith17:09:16

perhaps this is a hold over from the trauma of trying to do low latency real time work on 1990s laptop hardware

pataprogramming17:09:39

Oh, and Overtone’s MIDI support uses the host OS, rather than routing it through SC. So when I finally manage to coax Overtone into connecting (I had to up the number of allowed connections), I discovered that the Linux JVM was still trying to use the VM’s MIDI devices.

pataprogramming17:09:47

Yeah, bare metal is better…if only OS X had a real, multi-desktop tiling WM! So I’m trying to just do the control from the comfy VM environment, and run the synthesis/MIDI on the host OS.

pataprogramming17:09:23

I’ll give the SSH tunnel a shot, thanks for the assistance.

pataprogramming17:09:53

But it does look like there may be some sort of a bug in :start. Should I submit an issue for this? If I have some time, I can try to trace it down.

seancorfield17:09:42

Not sure it's a bug. For me, lein repl :start :host 0.0.0.0 :port 9009 works just fine, as does lein repl :start :host 127.0.0.1 :port 9009. If I try an internal IP (10.0.0.* for me), I get that same connection refused error -- which matches my experience with other server processes on my Mac.

pataprogramming18:09:53

@seancorfield: Is there a reason that it shouldn’t work, if starting one process with :headless and another process with :connect does? I’d sort of assumed that :start would be a combination of the two.

pataprogramming18:09:32

Guessing, it might be that :start always tries connect on the loopback interface…0.0.0.0 listens on loopback, so that would still work.

seancorfield18:09:56

@pataprogramming I'm not enough of a network guy to know -- I've just never seen lein connect over a private IP even when I start a headless REPL server on 0.0.0.0.