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 S. [email protected] 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)
Chris S. 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 K. 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
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/[email protected]/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.
Roxis wrote:
On Tuesday 02 September 2008, Volodymyr K. 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
[email protected]
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
[email protected]
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
[email protected]
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 
Paul
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 'Re: Trying to do the opposite of www.domain.com -> domain.com' - MARC
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:
-
add all IPs in default server:
server {
listen 1.1.1.1 default;
listen 2.2.2.2 default;
...
server_name _;
return 404;
}
-
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;
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
[email protected]
