Couldn't resolve configured domains #172
Comments
|
Same issue here. Troubleshooting steps didn't lead me to a resolution. Didn't have the /usr/local/ issues. Just: |
|
Installing from node package manager fixed this problem for me :) |
|
Same issue, haven't tried using NPM. |
|
Same issue using OS X 10.7.1 from the install script (haven't tried using NPM): *** Installing Pow 0.3.2...
*** Installing local configuration files...
/Users/lev/Library/LaunchAgents/cx.pow.powd.plist
*** Installing system configuration files as root...
/Library/LaunchDaemons/cx.pow.firewall.plist
*** Starting the Pow server...
*** Performing self-test...
*** Reloading system network configuration...
!!! Couldn't resolve configured domains (dev)
For troubleshooting instructions, please see the Pow wiki:
https://github.com/37signals/pow/wiki/Troubleshooting |
|
Ditto here on 10.7.1. Output: However, I can access my pow applications on port 20559 (i.e. http://myapp.dev:20559), so I can handle that just fine. Would be nice to not have to type the port # though. In case it helps, I tried changing my MAMP server to run on port 80 to test whether there was any problem setting something up on that port (I usually run it on port 8888, as per their default), which I was able to do just fine, so it seems as though nothing else is hogging port 80. When I change MAMP back to 8888, and then uninstall + reinstall pow, I am faced with the same "Couldn't resolve configured domains (dev)" message. |
|
Same issue here with v0.3.2 of Pow on OS X 10.6.6 Oddly though it does work, most of the time. |
|
I've found a quick work-around for my setup. Even though I wasn't running OSX's built-in version of apache before, I followed these instructions, and I now have the built-in apache install forwarding all *.dev requests to Pow on port 20559. I'm sure there's more than one thing that could cause this issue though, so YMMV. |
|
I'm also seeing this issue (https://gist.github.com/1211551) |
|
Seeing this on OS X 10.7.1 Lion, fresh install via 'curl get.pow.cx|sh' |
|
10.7.1 same sad story |
|
if you want to debug shell script install add -x after sh curl get.pow.cx | sh -x |
|
I’m having the same problem on OS X Lion Server 10.7.1. To provide some more information: running |
|
back to rails s unfortunately |
|
Same problem - Lion 10.7.1 |
|
Out of interest, how many of you guys experiencing this issue have installed OS X Lion Server (as opposed to those who have never had the Lion Server app installed)? I have a sneaking suspicion it may have something to do with the issue. |
|
I've never installed Server. On 27 Sep 2011, at 02:04, Coby Chapple wrote:
|
|
I never installed OS X Lion Server |
|
Same issue, Lion 10.7.1 Server |
|
definitely an issue on Lion server |
|
Not only Lion Server, a fresh install of Pow on regular Lion 10.7.2 behaves like this log. I dug into it a bit and it looks like the stuff that goes on in Lion changed a lot related to |
|
I’m not seeing @rfunduk’s problem where the launch daemons aren’t being set up—perhaps there’s two things going on here? I’m only seeing the same issue as @cobychapple whereby requests to |
|
@codyrobbins, you are able to uninstall (and verify all the bits are gone) and reinstall pow on 10.7.2? Nothing at all works for me, not After that, on future 'reinstalls', none of the domains resolve, so it may be that I'm actually seeing an unrelated issue. There are several tickets about this general "doesn't work at all" problem (such as #107 and #226). |
|
I don't recall ever seeing a node.js error like @rfunduk as part of this "Couldn't resolve configured domains" problem. What about other people? This might be a separate issue, as I definitely wouldn't call this a "doesn't work at all" problem—I'm using Pow right now (through the workaround with Apache I linked to above). |
|
@rfunduk—Yeah, I don’t get that error when installing on 10.7.2. For me the domains just don’t resolve to the Rack app without explicitly including the port Pow uses in the URL. |
|
@codyrobbins, that's unfortunate since this laptop is practically brand new (~2 weeks) with a fresh Lion install on it and it outright fails to install for me... :( @cobychapple, the fact that it fails to install (possibly only for me, and the people in #107, I suppose) means it doesn't work at all IMO :) I feel like getting apache involved means I might as well just install passenger and skip pow altogether. Stopping here so as not to fully hijack this issue with the install explosion problem. Anyone with access want to reopen #107? |
|
Pow failing to install and finding that it doesn't work at all for you seems to be a different issue than the one people are reporting in this issue thread, so I'd imagine the node exception issue (#107) will probably be a better place to discuss your issue (as that's what you're experiencing, unless I've misunderstood). As for Apache/Passenger, use whatever works. A five command workaround that lets me keep the convenience of Pow is all I need. |
|
10.7.2 with Server, all webservers stopped and disabled. http://[appname].dev:20559/ works great. Might be a nice refinement if pow simply indicated it's running on an alternate port because of [program]. Update 1: Determined the issue is not the node server, which runs perfectly. The issue seems to be related to the firewall rule that does the magic forwarding from 20559 => 80. Update 2: I've opened a feature request with one of the pow wrappers, powder, to ask for support of nonstandard ports specified in ~/.powconfig. |
|
+1 on this. Sent from my mobile device. Michael K. Madison II. On Nov 2, 2011, at 9:20 AM, Barry Allard
|
|
does anyone have a resolution to this yet? still getting this error. |
|
Still broken. |
|
I run into this error consistently, but only when I set POW_DOMAINS to something other than "dev". |
|
I don't think my error is relevant to this issue - I resolved it by copying the dev resolver in /etc/resolver for my other TLDs. |
|
I have OS X 10.7.3 Server and the only way I can get to Pow hosted applications is to use port 20559. The ipfw rule is not getting added. I tried the Apache suggestion from above and that doesn't appear to work either. I have a OS X 10.7.3 laptop that everything works great on. Here is the output from 'ipfw show' on the 10.7.3 Server: That is right after a reboot and logging in. |
|
I fixed this by editing /Library/LaunchDaemons/cx.pow.firewall.plist and changing the firewall rule to Then reload the rules You may also want to delete the old rule, which was number 01104 for me. |
|
The above fix by @altovideo doesn’t resolve the issue for me. I should note that as of Pow 0.3.2 I no longer get the original error when installing. However, Pow still doesn’t work without explicitly using port 20559. |
|
altovideo, Thanks! That worked. I was following https://github.com/37signals/pow/wiki/Running-Pow-with-Apache and both solutions failed. Finally, For the Impatient worked with the help of altovideo I didn't know how to delete the old rule. I am not familiar enough with ipfw. |
|
Had the same error on Lion 10.7.3 but got over it with the solution of altovideo |
|
After a few months, tonight I decided to uninstall/reinstall Pow and it installed without issues. No idea why this problem presented three months ago and doesn't now—it's not as if Pow's version changed at all. The bad news: now my apps won't start at all any more because I'm running into an issue that could be either #147 or #278 (except I'm using rbenv, not RVM like the people in those threads). 😢 |
|
Had same issue this morning when suddenly my rails app was not accessible. Reading @altovideo solution, I worked out that the forwarding rule from port 80 to 20559 just simply not there (not sure why this is the case since I didn't restart anything). Checking it by issuing: It only listed: 65535 allow ip from any to any Then running: Running the ipfw list, now I can see the port 80 to 20559 forward rule is there. |
|
@sstephenson this was still broken for me, as of today, on a clean 10.7.4 system. @altovideo fix worked perfectly for me! the ipfw went from to (after |
|
sudo ipfw delete 00100 and a reboot fixed this issue for me. Got the error after disabling Apache and reinstalling Pow. |
|
Did @altovideo 's fix work for anyone using Lion Server 10.7.4 and pow 0.4.0? Tried it with no luck at all. Pow is running but port forwarding doesn't seem to work. Using apache proxy didn't work either so I completely disabled httpd using launchctl. ipfw rule after pow installation: after @altovideo fix: MBP running 10.7.4 non-server worked fine from the start. |
|
Same issue, Lion 10.7.4 Server. Back to Thin. Sorry guys. |
|
Hi Guys, this was driving me nuts, because I also have Lion Server (because I wanted to get quad-core Mac Mini...) So I spend a half-day chasing for this crazy issue. Here are my final notes: On Lion server, there are basically 2 issues:
Let me know if this helps! |
|
Finally! The changes suggested by @kupinus above do indeed fix the problem for me on Lion Server 10.7.4. |
|
There is one remaining issue. On Lion Server, the ipfw rules are flushed periodically, probably by some daemon. I am now experimenting with adding the rule right into Server Admin GUI. As far as I know, this tool modifies the files in /etc/ipfilter. So I expect if we put the forward rule there, it might be loaded by the daemon.. I would happily disable this 'server' daemon, but I have read reports that it might block login, etc. So it would be better to not touch it and just add the forward rule to some "server friendly" location.... Does anyone know what is the correct way to programmatically add ipfw rules in Lion Server, so that it survives more than 2 hours? |
|
So it is working by adding the Probably the clean way would be to call Also, I noticed (by reading But because we need to stay compatible with standard Lion, probably the best way is to keep forwarding init where it is now. Only the ipwf rule needs to go to Having a strong Linux background, I am more and more surprised, how messy the OS X internals are :) |
|
@kupinus is correct, above, but also know that it's still crazy because under Mountain Lion, the ipfw rules are flushed by, er, something that I couldn't find. You can see evidence of the rule flush in the console log. Therefore, here's what I do (and perhaps what pow will need to do): sysctl -w net.inet.ip.forwarding=1 /etc/ipfilter/ipfw.conf is where the admin for the box is supposed to put custom rules. Adding them in a launchdaemon works, but only until this random rule flush/recreate process happens. You could probably just write the ip.fw.enable directly on install to get it going, but it will get reset on restart by rc.server unless you add the rule the ipfw.conf I've successfully gotten this to work on three Mountain Lion machines that were struggling. |
|
After installing Xcode5 developer preview on my mac pow stopped working. |
|
I was about to make a long post about how I could not get Pow to work, but then found a simple one that others may not know is a solution (if using Chrome):
|
|
+1 |
|
I was getting this too and on inspecting , turned out the fix for me was indicated by the following Verify this work I was getting an error like this: The default file contains a bunch of comments followed by Some other app, had pushed this in |
and others
I get the following when install pow. What am I doing wrong?
The text was updated successfully, but these errors were encountered: