Forum: NGINX Unix sockets for fastcgi_pass

Hello,

I just tested out using unix sockets for fastcgi_pass instead of the
often seen 127.0.0.1:9000.
It worked fine as far as I could tell.

Is there some reason no one seems to do this? I've read that sockets are
faster (don't know how much though) and probably more secure since they
aren't potentially exposed to the net. So that sounds better to me but I
see everyone seems to configure php using 127.0.0.1:9000.

Unix sockets only work on the same machine, right? So that would knock
it out for many situations. But for my use right now this would work. Is
there another reason not to do it?

Chris :)

On 9/1/08, Chris Savery <chrissavery@gmail.com> wrote:
>
> Unix sockets only work on the same machine, right? So that would knock it
> out for many situations. But for my use right now this would work. Is there
> another reason not to do it?
>
> Chris :)
>

I've heard of people having problems with sockets in the past, and
switching to TCP resolved it. (disclaimer: this information may be
old, and newer kernels/whatever could have removed that from being an
issue)

I've been using connections over localhost forever and never have had
any issues - so if it isn't broke, why fix it? It seems plenty fast
too :)

You won't be exposing your FastCGI engines to the network if you bind
it to localhost - it will only be accessable via the localhost
interface then.

Sockets can provide more security as you can use filesystem
permissions to control them (you can't easily allow/deny specific
users to specific ports), they could (for all I know) be faster, I
believe you can use them over NFS exports (but you probably wouldn't
want to, might as well just start FastCGI over TCP and bind it to a
network-accessable IP)

mike wrote:
>> aren't potentially exposed to the net. So that sounds better to me but I see
> I've heard of people having problems with sockets in the past, and
> interface then.
>
> Sockets can provide more security as you can use filesystem
> permissions to control them (you can't easily allow/deny specific
> users to specific ports), they could (for all I know) be faster, I
> believe you can use them over NFS exports (but you probably wouldn't
> want to, might as well just start FastCGI over TCP and bind it to a
> network-accessable IP)
>
>   
for freebsd (probably and linux too)
tcp sockets have some little overhead

http://www.mail-archive.com/freebsd-stable@freebsd.org/msg93193.html
http://freebsd.monkey.org/freebsd-performance/200703/msg00044.html

In real life you could use both ways (unix sockets and tcp ports),
proffered is that you feel more comfortable for himself.

As for me, I'm using unix sockets without any issues.

Chris Savery wrote:
> 
> Unix sockets only work on the same machine, right? So that would knock 
> it out for many situations. But for my use right now this would work. Is 
> there another reason not to do it?

I'm already using unix-sockets on my servers. with unix rights I even
can guarantee no one would access them except controlling user and
webserver.

Too bad apache mod_fastcgi doesn't work with them...

On Tuesday 02 September 2008, Volodymyr Kostyrko wrote:
> I'm already using unix-sockets on my servers. with unix rights I even
> can guarantee no one would access them except controlling user and
> webserver.
>
> Too bad apache mod_fastcgi doesn't work with them...

i does
http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer

Roxis wrote:
> On Tuesday 02 September 2008, Volodymyr Kostyrko wrote:
>> I'm already using unix-sockets on my servers. with unix rights I even
>> can guarantee no one would access them except controlling user and
>> webserver.
>>
>> Too bad apache mod_fastcgi doesn't work with them...
> 
> i does
> http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer

Last time i tried that it won't work for me.

Is there a way to limit the domains that can be requested on a server
directive?

Say I have

    server
        {
                listen 2.2.2.2:80;
                server_name x.com *.x.com;
                location /
                {
                        proxy_pass http://1.1.1.1;
                        proxy_redirect http://1.1.1.1/
http://$http_host/;
                        proxy_redirect default;
                        proxy_set_header        Host
$host;          ##Forwards host along
                        proxy_set_header        X-Forwarded-For
$remote_addr;   ##Sends realip to customer svr
                }
        }



Can I say, ONLY x.com and *.x.com can use this server?  Because I can
send any domain to it  and it passes it along to the backend server.
I would like to limit access to this.

Thanks

Paul

GloboTech Communications
Phone: 1-514-907-0050
Toll Free: 1-(888)-GTCOMM1
Fax: 1-(514)-907-0750
paul@gtcomm.net
http://www.gtcomm.net

On Tue, Sep 02, 2008 at 03:27:44PM -0400, Paul wrote:

>                {
> 
> 
> 
> Can I say, ONLY x.com and *.x.com can use this server?  Because I can 
> send any domain to it  and it passes it along to the backend server.
> I would like to limit access to this.

     server {
         listen 2.2.2.2:80 default;
         server_name  _;
         return 404;
     }

     server {
         listen 2.2.2.2:80;
         server_name  x.com *.x.com;

         # you may also add possibility to use IP only in browsers
         # and no Host header at all using:
         #server_name  2.2.2.2  "";

         ...
     }

Look also http://marc.info/?l=nginx&m=122025301723208&w=2

You could supply a catch-all (ie. _;) server configuration and
redirect that to a local 404 page served directly by nginx.
--
Scott Larson
Network Administrator

Wiredrive
4216 3/4 Glencoe Ave
Marina Del Rey, CA 90292
t 310.823.8238
stl@wiredrive.com
http://www.wiredrive.com

Igor, Scott..
I have a whole bunch of server configurations on a whole lot of ip
addresses..
Is there a way to specify the catch all for ALL the ip addresses or
would i have to do a server _ for every ip address?
(I'm not using a 'listen 80;' but rather listen 1.1.1.1:80 1.1.1.2:80
etc etc)
Right now I'm using a if $host does not equal .*domain\.com.*,
proxy_pass http://127.0.0.1

Thanks

Is there a reason you're not using 'listen 80'?  That would bind
to all your IPs and then you wouldn't need to do all the extra catch-
all configurations.
--
Scott Larson
Network Administrator

Wiredrive
4216 3/4 Glencoe Ave
Marina Del Rey, CA 90292
t 310.823.8238
stl@wiredrive.com
http://www.wiredrive.com

Using apache and other stuff on the save server that listens on other
ips, plus have some ips that are just for other services besides web and
don't need/want port 80 open on those..
I never use listen on * for anything, just a habit that I got into a
long time ago because I'm a big security freak :P

Paul

Well server_name only falls under the context of the server
directive so in this instance it would look like you're stuck
declaring a catch-all for each IP in this sort of configuration.  I
typically set things up as firewall->nginx->apache.  It ends up
leaving only one bit of software exposed at each layer and simplifies
my life considerably.  Putting nginx at that layer lets me pump static
content through it rather than bang it through Apache for some serious
performance improvement.  But whatever, all situations are different.
--
Scott Larson
Network Administrator

Wiredrive
4216 3/4 Glencoe Ave
Marina Del Rey, CA 90292
t 310.823.8238
stl@wiredrive.com
http://www.wiredrive.com

On Tue, Sep 02, 2008 at 04:23:58PM -0400, Paul wrote:

> I have a whole bunch of server configurations on a whole lot of ip 
> addresses..
> Is there a way to specify the catch all for ALL the ip addresses or 
> would i have to do a server _ for every ip address?
> (I'm not using a 'listen 80;' but rather listen 1.1.1.1:80 1.1.1.2:80 
> etc etc)
> Right now I'm using a if $host does not equal .*domain\.com.*, 
> proxy_pass http://127.0.0.1 

You can not use catching all server listening on *:80 only.
When nginx detects that it has a server listening on a IP, it uses that
server configuraiton, and if the server is single for that IP, it 
becames
default server for the IP. Therefore you have two choices:

1) add all IPs in default server:

          server {
                   listen 1.1.1.1 default;
                   listen 2.2.2.2 default;
                   ...
                   server_name  _;
                   return  404;
          }

2) add single line server before/after each server instead of "if 
$host":

          server { listen 2.2.2.2 default; server_name _; return 404; }

          server {
                   listen 2.2.2.2;