search

ysbaddaden / prax

Rack proxy server for development
http://ysbaddaden.github.io/prax/
Other
475 stars 49 forks source link

Prax not working on ubuntu 14.04 LTS #87

Closed khanimdad closed 9 years ago

khanimdad commented 10 years ago

After setting it up by following the instruction from here https://github.com/ysbaddaden/prax when i hit http://trunk.dev, http://trunk.dev/, trunk.dev, or trunk.dev/ then it does not work in any case but results in search page from my ISP.

Any idea on how can i fix it?

ysbaddaden commented 10 years ago

Your ISP's DNS resolve wants to be smart and always replies with it's search engine IP instead of returning nothing (ie. no such domain). You may edit /etc/nsswitch.conf to put the prax resolver before dns, so *.dev domains will be resolved to localhost before reaching your ISP.

OpenDNS has the same problem, but at least you can configure this behavior (reply nothing if the domain can't be found). An alternative is to use another DNS resolver, like Google DNS, or to install/configure dnsmasq to always reply 127.0.0.1 for *.dev domains.

khanimdad commented 10 years ago

I have already edit the /etc/nsswitch.conf file, below is its content, but still i see the same issue passwd: compat group: compat shadow: compat

hosts: files mdns4_minimal [NOTFOUND=return] dns prax mdns4 networks: files

protocols: db files services: db files ethers: db files rpc: db files

ysbaddaden commented 10 years ago

Damn, I have no clue :(

What is getent hosts trunk.dev displaying? It should say ::1 trunk.dev or 127.0.0.1 trunk.dev.

khanimdad commented 10 years ago

Here is the result of getent hosts trunk.dev imdad@Youtoo:~/Youtoo/devold$ getent hosts trunk.dev ::1 trunk.dev

ysbaddaden commented 10 years ago

Damn, the DNS resolution is correct. Did you fully restart the browser? Chrome for example is still there in the background. I'll try Trusty when I have some time available (I'm still under Precise).

khanimdad commented 10 years ago

Instead of just restarting the browser several time i rebooted by machine, but no luck yet. ;)

ysbaddaden commented 10 years ago

Then I have no clue what's happening :(

marcusg commented 10 years ago

I have the same problem, everything looks good, no errors. But I can't open the page with firefox or chrome :(

ysbaddaden commented 10 years ago

I upgraded to 14.04 (from 12.04) two weeks ago and I have no problem. Maybe it's:

zeitnot commented 10 years ago

I have the same problem @ysbaddaden.

ysbaddaden commented 10 years ago

If someone could investigate, that would be great. I can't reproduce the problem :(

AskarZinurov commented 10 years ago

I saw in logs:

I, [2014-08-29T14:43:07.203883 #5901]  INFO -- : Spawning application 'azs' [/home/ask/projects/teplokontrol/azs]
E, [2014-08-29T14:43:21.891005 #5901] ERROR -- : NoMethodError: undefined method `split' for nil:NilClass
  /opt/prax/lib/prax/request.rb:73:in `host'
  /opt/prax/lib/prax/handler.rb:57:in `app_name'
  /opt/prax/lib/prax/handler.rb:17:in `handle'
  /opt/prax/lib/prax.rb:20:in `perform'
  /opt/prax/lib/prax/microworker.rb:84:in `block in work'
  /opt/prax/lib/prax/microworker.rb:77:in `each'
  /opt/prax/lib/prax/microworker.rb:77:in `work'
  /opt/prax/lib/prax/microworker.rb:63:in `block in spawn'
I, [2014-08-29T14:43:21.891164 #5901]  INFO -- : Respawning failed worker
ysbaddaden commented 10 years ago

@AskarZinurov that's a known bug that happens when for some unknown reason the request doesn't have a "host: xxx.dev" header. I don't think this is related, because I got it already under 12.04 using various browsers, and still haven't been capable to debug it :cry:

AskarZinurov commented 10 years ago

@ysbaddaden I found some projects, which successfully working with prax. Maybe some gem dependencies failing with prax. For my case it was dotenv-rails, after removing this gem and .env file site becomes working. Also disappeared notice in prax foreground mode:

/tmp/15063.praxenv: line 1: export: `SOME_VARIABLE:': not a valid identifier
ysbaddaden commented 10 years ago

I suspect that the prax bash script incorrectly parses your .env. Can you open open an issue about it, with a reproducible .env? I'm also a user of dotenv on some projects —only for developers that don't use Prax of course!

Edit: got it, prax expects NAME=value declarations but you are using NAME: value?

AskarZinurov commented 10 years ago

@ysbaddaden https://github.com/ysbaddaden/prax/issues/95

araslanov-e commented 10 years ago

myapp.dev:3000 only works whan cd ~/Work/myapp && rails s

ysbaddaden commented 10 years ago

Then DNS resolution is fine. Maybe the iptables rules to redirect :80 => :20559 are faulty?

What happens when you start prax with: PRAX_DEBUG=1 prax start --foreground and try to reach both http://myapp.dev and http://myapp.dev:20559 ?

ysbaddaden commented 10 years ago

Also, what's the output of sudo iptables -t nat -L -n ?

You should see rules like the following ones:

Chain PREROUTING (policy ACCEPT)                                                           
target     prot opt source               destination                                       
REDIRECT   tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:80 redir ports 20559 
REDIRECT   tcp  --  0.0.0.0/0            192.168.0.0/24       tcp dpt:443 redir ports 20558

Chain OUTPUT (policy ACCEPT)                                                               
target     prot opt source               destination                                       
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:80 redir ports 20559 
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:443 redir ports 20558
araslanov-e commented 10 years ago

With PRAX_DEBUG=1 prax start --foreground ... nothin: I, [2014-09-05T14:29:28.777107 #4704] INFO -- : Prax is ready to receive connections on :20559.

araslanov-e commented 10 years ago 
$ sudo iptables -t nat -L -n

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:443 redir ports 20558

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
araslanov-e commented 10 years ago

$ PRAX_DEBUG=1 prax start --foreground open http://myapp.dev:20559 and ...

I, [2014-09-05T15:14:20.655168 #7990]  INFO -- : Prax is ready to receive connections on :20559.
I, [2014-09-05T15:14:25.770502 #7990]  INFO -- : Spawning application 'myapp' [/home/araslanov_e/work/myapp]
D, [2014-09-05T15:14:25.770654 #7990] DEBUG -- : ["/opt/prax/bin/racker", "--server", "/home/araslanov_e/.prax/_sockets/myapp.sock"]
/home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler/spec_set.rb:92:in `block in materialize': Could not find rake-10.3.2 in any of the sources (Bundler::GemNotFound)
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler/spec_set.rb:85:in `map!'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler/spec_set.rb:85:in `materialize'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler/definition.rb:133:in `specs'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler/definition.rb:178:in `specs_for'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler/definition.rb:167:in `requested_specs'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler/environment.rb:18:in `requested_specs'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler/runtime.rb:13:in `setup'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler.rb:119:in `setup'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.5.3/lib/bundler/setup.rb:17:in `<top (required)>'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /home/araslanov_e/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
D, [2014-09-05T15:14:55.774463 #7990] DEBUG -- : Killing claim_sk (8054)...
araslanov-e commented 10 years ago

I use RVM with gemset

ysbaddaden commented 10 years ago
araslanov-e commented 10 years ago

Yes, I have looked about RVM, now it worked, thanks.

ysbaddaden commented 9 years ago

I finally installed Trusty on a new computer, and got the bug. A primary investigation led to what has been discovered: the iptables routing is non functional on a fresh install of Ubuntu 14.04.

A fix is to disabled the PREROUTING routes in the /etc/init.d/prax script to restore the localhost redirection (hence myapp.dev:80 gets redirected to 127.0.0.1:20559.

Now I need a proper fix to reenable the external redirection, like when accessing Prax from a mobile device and using the xip.io name resolution...

ysbaddaden commented 9 years ago

After more trials and errors, I eventually got the whole redirections working. The problem is, I got it working with the original iptables script... I tried to reboot, but it still works. I'm definitely lost on what caused the bug!

straydogstudio commented 9 years ago

For what it is worth, I have a fresh 14.04 install that shows the firewall rules are working, the resolving is working, but in debug mode I see the following error:

... Could not find rake-10.3.2 in any of the sources (Bundler::GemNotFound)

My .praxconfig file is:

rvm_path="$HOME/.rvm/"
source "$rvm_path/scripts/rvm"
rvm ruby-2.1.3
cd $PWD

I can of course run the server manually, so it shouldn't be the bundled gems.

Any ideas on what to check next?

ysbaddaden commented 9 years ago

Maybe the RVM script isn't enough. Can you try the different .praxconfig solutions proposed in the RVM issues?

I'm not a RVM user myself, and it's a pain to have it working with Prax, everything I try just doesn't work —while alternatives like no version manager (my case now) or rbenv (me some months back) or chruby and working perfectly.

straydogstudio commented 9 years ago

@ysbaddaden It turned out to be a simple issue. I did not notice that .praxconfig was to go in my home directory, not the project directory. I realized this after renaming .praxconfig to .praxrc got things working. Doh! :P

karlwilbur commented 9 years ago

@khanimdad, In your NSSwitch config, you need to have prax before dns. You have

hosts: files mdns4_minimal [NOTFOUND=return] dns prax mdns4

It should be:

hosts: files mdns4_minimal [NOTFOUND=return] prax dns mdns4

Refer to the Slowness section in the README.

@ysbaddaden, We should update the documentation to explain that with certain ISPs (those that choose to break DNS for their customers by lying and return a "valid" answer for a query that should have no valid answer), prax need to be used before querying the DNS, since that ISP's DNS is broken. Thus the Slowness section of the README doesn't only apply to slowness.

karlwilbur commented 9 years ago

FTR, I am using Ubuntu 14.04 on all my machines now with no problems. I also have 4 other devs working for me and I have them all using prax, also with no issues ...except for the occasional forgetting to prax restart to load changes in config and initializers. :-)

ysbaddaden commented 9 years ago

The prax nsswitch lib is now set before dns by default, since 0369cf9bc244078580d2a467f3595307cbe5af4b the whole slowness thing should be moved to the wiki in a DNS section.

adamcrown commented 9 years ago

This is likely an unrelated issue but I thought I'd mention it here in case somebody else is having the same problem.

One day I just started having issues with prax on my Ubuntu 14.04 machine but only from Chrome. Everything else worked fine. I ran into this thread and disabling Built-in Asynchronous DNS in chrome://flags fixed the issue for me.

I saw the same undefined method 'split' for nil:NilClass that others were seeing and looking into the code it seemed that header('Host') was returning nil.

Not sure how Built-in Asynchronous DNS is related to a missing host header but maybe this info will be helpful for somebody else.

emanuil-tolev commented 9 years ago

sounds like the Ubuntu 14.04 bug is related to iptables rules not working (PREROUTING should state 192.168.0.0/24 not 0.0.0.0/24)

Hm, I had prax working for a couple of weeks, but trying to use it now about another week later, I get Connection Refused in the browser. Ubuntu 14.04.

# sudo iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:443 redir ports 20558

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Prax itself seems to work

# PRAX_DEBUG=1 prax start -f
I, [2015-01-16T16:11:52.433882 #10168]  INFO -- : Prax is ready to receive connections on :20559 and :20558.

But when I try to access myapp.dev:20558 or :20559 I get:

I, [2015-01-16T16:15:44.407916 #10168]  INFO -- : Spawning application 'myapp' [/home/emanuil/cl/myapp]
D, [2015-01-16T16:15:44.408042 #10168] DEBUG -- : ["/home/emanuil/software/prax/bin/racker", "--server", "/home/emanuil/.prax/_sockets/myapp.sock"]
D, [2015-01-16T16:15:46.101946 #10168] DEBUG -- : Application 'myapp' is ready on unix:/home/emanuil/.prax/_sockets/myapp.sock
E, [2015-01-16T16:15:54.331335 #10168] ERROR -- : NoMethodError: undefined method `split' for nil:NilClass
  /home/emanuil/software/prax/lib/prax/request.rb:73:in `host'
  /home/emanuil/software/prax/lib/prax/handler.rb:57:in `app_name'
  /home/emanuil/software/prax/lib/prax/handler.rb:17:in `handle'
  /home/emanuil/software/prax/lib/prax.rb:20:in `perform'
  /home/emanuil/software/prax/lib/prax/microworker.rb:84:in `block in work'
  /home/emanuil/software/prax/lib/prax/microworker.rb:77:in `each'
  /home/emanuil/software/prax/lib/prax/microworker.rb:77:in `work'
  /home/emanuil/software/prax/lib/prax/microworker.rb:63:in `block in spawn'
I, [2015-01-16T16:15:54.331406 #10168]  INFO -- : Respawning failed worker
/home/emanuil/.rvm/gems/ruby-2.1.2/gems/rack-1.5.2/lib/rack/urlmap.rb:53:in `+': no implicit conversion of Fixnum into String (TypeError)
        from /home/emanuil/.rvm/gems/ruby-2.1.2/gems/rack-1.5.2/lib/rack/urlmap.rb:53:in `block in call'
        from /home/emanuil/.rvm/gems/ruby-2.1.2/gems/rack-1.5.2/lib/rack/urlmap.rb:50:in `each'
        from /home/emanuil/.rvm/gems/ruby-2.1.2/gems/rack-1.5.2/lib/rack/urlmap.rb:50:in `call'
        from /home/emanuil/software/prax/lib/racker/handler.rb:16:in `block in handle'
        from /home/emanuil/software/prax/lib/racker/handler.rb:43:in `catch_error'
        from /home/emanuil/software/prax/lib/racker/handler.rb:16:in `handle'
        from /home/emanuil/software/prax/lib/racker.rb:16:in `perform'
        from /home/emanuil/software/prax/lib/prax/microworker.rb:84:in `block in work'
        from /home/emanuil/software/prax/lib/prax/microworker.rb:77:in `each'
        from /home/emanuil/software/prax/lib/prax/microworker.rb:77:in `work'
        from /home/emanuil/software/prax/lib/prax/microworker.rb:63:in `block in spawn'
D, [2015-01-16T16:15:58.357013 #10168] DEBUG -- : Killing myapp (10721)...
I, [2015-01-16T16:15:58.357279 #10168]  INFO -- : Forcing restart of myapp (/home/emanuil/cl/myapp)
I, [2015-01-16T16:15:58.357334 #10168]  INFO -- : Spawning application 'myapp' [/home/emanuil/cl/myapp]
# aaand off we go again, same error

Prax config:

# cat ~/.praxconfig
rvm_path="$HOME/.rvm/"
source "$rvm_path/scripts/rvm"
cd $PWD

EDIT:

NSSwitch config:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files prax mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis
ysbaddaden commented 9 years ago

I recently pushed a few commits on master to fix the split error on missing host header: #113

Please upgrade Prax and tell me if it still happens.

emanuil-tolev commented 9 years ago

Yep, did upgrade, still happening :(.

git pull
./bin/prax install
# restart browser
cd <myapp>
prax link
# stdout said
# rm -f '/home/emanuil/.prax/myapp'
# ln -s '/home/emanuil/cl/myapp' '/home/emanuil/.prax/myapp'
# the symlink is correct and the folder is there, so this bit is doing the right thing
prax start -f

But when I hit myapp.dev it never makes it to prax - I can see no lines are appearing in the log, and I get connection refused.

PING myapp.dev (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.039 ms

Iptables after prax upgrade (it said it was setting up firewall rules):

# sudo iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:443 redir ports 20558

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Now, trying to connect to localhost:20558 and :20559

E, [2015-01-19T18:36:50.150387 #612] ERROR -- : Prax::NoSuchApp: Prax::NoSuchApp
  /home/emanuil/software/prax/lib/prax/application.rb:16:in `initialize'
  /home/emanuil/software/prax/lib/prax/spawner.rb:49:in `new'
  /home/emanuil/software/prax/lib/prax/spawner.rb:49:in `spawn'
  /home/emanuil/software/prax/lib/prax/spawner.rb:23:in `block in get'
  /home/emanuil/software/prax/lib/prax/spawner.rb:17:in `synchronize'
  /home/emanuil/software/prax/lib/prax/spawner.rb:17:in `get'
  /home/emanuil/software/prax/lib/prax/handler.rb:62:in `app'
  (erb):3:in `render_to_string'
  /home/emanuil/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/erb.rb:850:in `eval'
  /home/emanuil/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/erb.rb:850:in `result'
  /home/emanuil/software/prax/lib/prax/render.rb:24:in `render_to_string'
  /home/emanuil/software/prax/lib/prax/render.rb:9:in `render'
  /home/emanuil/software/prax/lib/prax/handler.rb:33:in `rescue in handle'
  /home/emanuil/software/prax/lib/prax/handler.rb:47:in `handle'
  /home/emanuil/software/prax/lib/prax.rb:21:in `perform'
  /home/emanuil/software/prax/lib/prax/microworker.rb:84:in `block in work'
  /home/emanuil/software/prax/lib/prax/microworker.rb:77:in `each'
  /home/emanuil/software/prax/lib/prax/microworker.rb:77:in `work'
  /home/emanuil/software/prax/lib/prax/microworker.rb:63:in `block in spawn'
I, [2015-01-19T18:36:50.152692 #612]  INFO -- : Respawning failed worker

After a few connection attempts (notably perhaps after changing the port I'm accessing from 20558 to 20559 or vice versa), it seems to just hang. The browser stays in "Waiting for response". Ctrl+C-ing prax at this point gives this little piece:

^C/home/emanuil/software/prax/lib/prax/ssl.rb:18:in `accept': SSL_accept returned=1 errno=0 state=unknown state: http request (OpenSSL::SSL::SSLError)
        from /home/emanuil/software/prax/lib/prax/ssl.rb:18:in `accept_nonblock'
        from /home/emanuil/software/prax/lib/prax/microserver.rb:77:in `block in select'
        from /home/emanuil/software/prax/lib/prax/microserver.rb:72:in `each'
        from /home/emanuil/software/prax/lib/prax/microserver.rb:72:in `select'
        from /home/emanuil/software/prax/lib/prax/microserver.rb:31:in `block in run'
emanuil-tolev commented 9 years ago

After a few connection attempts (notably perhaps after changing the port I'm accessing from 20558 to 20559 or vice versa), it seems to just hang

Actually the hanging and SSL error on exit seem to happen as soon as I access 20558. 20559 returns No data received in the browser, and the NoSuchApp error that can be seen above.

ysbaddaden commented 9 years ago

There are a bunch of problems here.

I think the iptables rules arent working, hence no redirection :80 to :20559. Don't know why, thought.

The problem on :20559 is most certainly that prax can't find the host anywhere in your HTTP request, so yeah, the application can't be found.

Can you send the request the browser makes somewhere?

karlwilbur commented 9 years ago

Trying to connect to localhost:20558 or localhost:20559 will not work with prax. Prax expects the host name to match an application name in the format myapp.dev.

Where you ran:

cd <myapp>
prax link

Prax makes a link to the app, in this case called myapp:

# ln -s '/home/emanuil/cl/myapp' '/home/emanuil/.prax/myapp'

After those steps have been done, Prax's DNS resolution and request routing will forward any requests to myapp.dev to the app that lives in /home/emanuil/cl/myapp. This is not possible if you use localhost.

Because you can have many apps running at the same time, Prax uses the hostname of the request for determining to which app the request should be routed. The hostname much match the liink name in ~/.prax (which usually marches the name pf the app's root folder).

FWIW, I have been successfully using Prax with several rails apps on all of my Ubuntu 14.04 machines (2 desktops and 3 laptops) and so have all of my contractors. I have installed Prax several times on vanilla Ubuntu 14.04 machines with total success (I don't use SSL as much as I expected so I am not as certain about SSL, but I seem to recall that it works fine too once you get past the security warning).

Here's my output from iptables:

karl@karl-S500CA [16:11:27] [~] 
-> % sudo iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:443 redir ports 20558

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

@emanuil-tolev, I noticed that in your PREROUTING table, you have duplicate entries. I don't think this would be a problem, but it might be. Try stopping the prax "service" to remove the iptables entries then restart to reapply. Does that change anything for you?

Here is what I mean:

karl@karl-S500CA [16:15:29] [~] 
-> % sudo iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:443 redir ports 20558

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
karl@karl-S500CA [16:15:31] [~] 
-> % sudo service prax stop    
karl@karl-S500CA [16:15:34] [~] 
-> % sudo iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
karl@karl-S500CA [16:15:35] [~] 
-> % sudo service prax start   
karl@karl-S500CA [16:15:38] [~] 
-> % sudo iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:443 redir ports 20558

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
karl@karl-S500CA [16:15:39] [~] 
-> %
karlwilbur commented 9 years ago

@emanuil-tolev,

Also, try running rails c and/or rails s in your app's root. I have had several instances where my app failed to start because of something in the app (some stupid thing that I did in the app) and it was hidden from me because it never appeared in the prax log. Using rails s will sometime make the issue very obvious.

khanimdad commented 9 years ago

Now my app is running on http://unicircles.dev:3000, but the problem is that a) I do not want port number here (Not sure how to avoid it) b) I still need to keep app server running (ie "rails server" )

Any idea on how to fix a and b above?

karlwilbur commented 9 years ago

Don't run "rails server". Just connect to http://unicircles.dev/ (without the port).

Make sure that you have run both of these in your terminal:

sudo service prax start

and 

prax start

Sometimes, your if your app has issues starting (not prax-related), you can use rails s or rails c to debug app start up issues. Once you have resolved those start up issues, you should do prax restart.

zeitnot commented 9 years ago

@karlwilbur I have the same problem with @khanimdad. Without port number and rails s it does not work. After $ prax start I run $ sudo iptables -t nat -L -n and that gives the following output.

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:443 redir ports 20558

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
RETURN     all  --  192.168.122.0/24     224.0.0.0/24        
RETURN     all  --  192.168.122.0/24     255.255.255.255     
MASQUERADE  tcp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  udp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  all  --  192.168.122.0/24    !192.168.122.0/24    
MASQUERADE  all  --  10.0.3.0/24         !10.0.3.0/24
karlwilbur commented 9 years ago

@zeitnot You need to have run prax link link in your project directory. Here is a complete example on Ubuntu 14.04 with Rbenv installed:

git clone https://github.com/ysbaddaden/prax.git /opt/prax
cd /opt/prax/ && sudo ./bin/prax install
sudo service prax start
cd ~/Projects/ExampleApp/
git clone git@git.kandrsoftware.com:exampleapp.git
cd exampleapp
prax link
git checkout develop
rbenv install `cat .ruby-version`
bundle install
cp config/settings.local{.example,}.yml
rake db:create && rake db:migrate && rake db:seed
prax stop && prax start
google-chrome http://exampleapp.dev/

I also highly recommend Ubuntu Wart Removal (https://github.com/ab/ubuntu-wart-removal). Particularly disable-dnsmasq.sh. That might be your problem.

Here's the output of my sudo iptables -t nat -L -n:

karl@karl-S500CA [16:46:00] [~/Projects/ExampleApp/exampleapp] [master *]
-> % sudo iptables -t nat -L -n
[sudo] password for karl: 
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443 redir ports 20558

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:80 redir ports 20559
REDIRECT   tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:443 redir ports 20558

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
karlwilbur commented 9 years ago

This might help with troubleshooting... Tail the prax logs. To do this run:

tail -fn0 ~/.prax/_logs/prax.log ~/.prax/_logs/exampleapp.log

Here is that run on my machine:

karl@karl-S500CA [17:00:13] [~/Projects/ExampleApp/exampleapp] [master *]
-> % tail -fn0 ~/.prax/_logs/prax.log ~/.prax/_logs/exampleapp.log 
==> /home/karl/.prax/_logs/prax.log <==

==> /home/karl/.prax/_logs/exampleapp.log <==

Then in a new tab, run:

prax stop && prax start && google-chrome http://exampleapp.dev/

Here is my tail output:

karl@karl-S500CA [17:00:13] [~/Projects/ExampleApp/exampleapp] [master *]
-> % tail -fn0 ~/.prax/_logs/prax.log ~/.prax/_logs/exampleapp.log 
==> /home/karl/.prax/_logs/prax.log <==

==> /home/karl/.prax/_logs/exampleapp.log <==

==> /home/karl/.prax/_logs/prax.log <==
I, [2015-02-07T17:00:33.473679 #31758]  INFO -- : Prax is ready to receive connections on :20559 and :20558.
I, [2015-02-07T17:00:51.892546 #31758]  INFO -- : Spawning application 'exampleapp' [/home/karl/Projects/ExampleApp/exampleapp]

==> /home/karl/.prax/_logs/exampleapp.log <==
bundle exec ruby /opt/prax/bin/../lib/racker/command.rb --server /home/karl/.prax/_sockets/exampleapp.sock
I, [2015-02-07T17:00:53.191679 #31856]  INFO -- : Racker is ready to receive connections on /home/karl/.prax/_sockets/exampleapp.sock.
khanimdad commented 9 years ago

@karlwilbur , sorry still not working, i did what you asked for eg stopped rails server then sudo service prax start and prax start

http://unicircles.dev returns This webpage is not available

karlwilbur commented 9 years ago

@khanimdad, did you tail the logs? Please post the last few lines of both the prax log and the app log.

Also, try prax stop then prax start.

khanimdad commented 9 years ago

@karlwilbur , here is my prax log file, but app log file is empty.

imdad@Youtoo:~/Youtoo/devold$ tail -n 20 -f ~/.prax/_logs/prax.log I, [2015-02-07T17:22:46.976814 #10960] INFO -- : Forcing restart of unicircles (/home/imdad/Youtoo/devold) I, [2015-02-07T17:22:46.978613 #10960] INFO -- : Spawning application 'unicircles' [/home/imdad/Youtoo/devold] E, [2015-02-07T17:22:52.850751 #10960] ERROR -- : ArgumentError: bad argument (expected URI object or URI string) /home/imdad/.rvm/rubies/ruby-1.9.3-p547/lib/ruby/1.9.1/uri/common.rb:996:in URI' /opt/prax/lib/prax/request.rb:136:indetermine_host' /opt/prax/lib/prax/request.rb:75:in host' /opt/prax/lib/prax/handler.rb:66:inapp_name' /opt/prax/lib/prax/handler.rb:17:in handle' /opt/prax/lib/prax.rb:21:inperform' /opt/prax/lib/prax/microworker.rb:84:in block in work' /opt/prax/lib/prax/microworker.rb:77:ineach' /opt/prax/lib/prax/microworker.rb:77:in work' /opt/prax/lib/prax/microworker.rb:63:inblock in spawn' I, [2015-02-07T17:22:52.850942 #10960] INFO -- : Respawning failed worker I, [2015-02-07T17:23:17.086217 #10960] INFO -- : Forcing restart of unicircles (/home/imdad/Youtoo/devold) I, [2015-02-07T17:23:17.086380 #10960] INFO -- : Spawning application 'unicircles' [/home/imdad/Youtoo/devold] I, [2015-02-07T17:33:30.285394 #10960] INFO -- : Killing unicircles: expired TTL I, [2015-02-08T09:31:27.529681 #14942] INFO -- : Prax is ready to receive connections on :20559 and :20558. I, [2015-02-08T10:03:29.787563 #4348] INFO -- : Prax is ready to receive connections on :20559 and :20558. I, [2015-02-08T12:14:40.867720 #8023] INFO -- : Prax is ready to receive connections on :20559 and :20558.

ysbaddaden commented 9 years ago

Prax fails because it can't find the Host in your request. Either the Host header is missing or it's not provided in the URI or something.

It happens sometimes but I have no idea what's going on. I can't replicate and never got dumped requests to understand what's going on :-(

See #113 and #112