anonymous-one's questions

We are noticing this on a number of our openvpn clients:

[root@box ~]# netstat -tulpn | grep openvpn
udp        0      0 0.0.0.0:53950               0.0.0.0:*                               1562/openvpn
[root@box ~]#

I am having a hard time finding any info via google regarding what is causing openvpn to open this random UDP port.

This port is random as it differs on each box, and when one restarts openvpn.

Any ideas?

We use sshfs in quite a few situations.

We were wondering if there was a way to log the read / writes made to the sshfs mounts we have so we could optimize things on our local side (eg: tweaking cache, locally caching objects, etc).

Any ideas?

We have a small script that essentially does the following:

A) Capture packets using tcpdump and pipe to output file.
B) Run our own clean + sort script on output file.
C) Display results using | sort | etc etc...

So, we were wondering if there is a tcpdump parameter that sets the number of packets tcpdump will capture before exiting?

Thanks.

Pre briefing:

Although my question is broad on purpose, I am dealing with nginx connecting to php-fpm (fcgi), which is served via a local socket (/tmp/somesocket.socket).

Nginx has a setting to keepalive connections to fcgi backends ( http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_keep_conn ).

This is what my question relates to.

Question:

In linux, when making connection to local sockets, does such a thing as keepalives exist?

Would having a connection kept alive remove (even a tiny bit) some overhead related to creation / teardown of the connection?

Thanks.

we are seeing the following:

[root@primary data]# netstat -s | grep buffer ; sleep 10 ; netstat -s | grep buffer
    20560 packets pruned from receive queue because of socket buffer overrun
    997586 packets collapsed in receive queue due to low socket buffer
    20587 packets pruned from receive queue because of socket buffer overrun
    998646 packets collapsed in receive queue due to low socket buffer
[root@primary data]#

Bare in mind, the above is a freshly rebooted box... About 1hour uptime. We recently had a box that was up 2 months, and these counteres will into the high millions (XXX million).

We have tried changing various sysctl variables...

Here are our sysctl variables which I believe are related:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

Does anyone know how to resolve these pruned pakcets due to socket buffer overrun / packets colapsing (which I understand isnt as bad as the pruned packets)?

Thanks.

I was wondering if someone could help me with the following iptables rule:

We would like to allow ANY and ALL locally originating (as in, on the server running iptables) traffic.

DNS, HTTP, etc... all of it. Any connection initiated by the server running iptables should be allowed.

Currently we are using basically OUTPUT default policy, ACCEPT. Is this correct? Inputs are blocked, so I am assuming this means that the connections (except those we allow) cannot be started because they will be dropped before our side can hit the OUTPUT policy?

Sorry, my iptables skills are weak ;)

Thank you kindly.

We would like to move away from sshfs to nfs.

The last thing holding us back is the fact that rpcbind (which I assume is required for nfs to work) does not allow you to specify the TCP (not UDP) IP that it binds to.

There is the -h flag, but this is only for the UDP ports it opens up. this does not affect the TCP ports, they still open on 0.0.0.0:...

Does anyone know how we can secure rpcbind by not exposing it to our public interface?

Or even better, is there a way to use nfs without rpcbind?

Thanks!

The nginx wiki states:

break - completes processing of current rewrite directives and non-rewrite processing continues within the current location block only.

Is this to say that:

If the rewrite pattern matches, process the rewrite (rewrite to target) but do not process any of the other rules in the location block, and process all other (cache, proxy, etc) directives in the location block?

I am talking about the break flag as per:

PATTERN TARGET FLAG

Not the "break;" directive.

UPDATE:

The scenario I was thinking of using this for is as follows, a simple location with multiple rewrites:

location /path/ {
    rewrite ^/user_request_one$ /target_one;
    rewrite ^/user_request_two$ /target_two;
    ... other directives ...
}

Perhaps I dont understand fully how nginx handles rewrites, but in the above, if target_one is matched, will nginx still test rewrite rule target_two? Would adding a break flag to target_one instruct nginx to stop parsing any further rewrite rules?

The main reason I am asking is because we have some location blocks with a number of rewrite rules and I am unsure weather nginx is testing rewrite patterns "further down" even if one is matched "near the top". These rewrites are very unique, so if one is hit, there is absolutely no reason for nginx to test any others in the same location block. We just want to make sure we are not wasting any precious cpu cycles as this is a fairly loaded server.

Hope this helps.

Thanks.

We have recently found out about nginxes post_action.

We were wondering it there was a way to use this directive if a proxy cache hit is made?

The flow we were hoping on is as follows:

1) User request comes in
2) If cache HIT goto A / If cache MISS goto B

A) 1) Serve Cached Result
A) 2) post_action to another url on the backend

B) 1) Server request from backend
B) 2) Store result from backend

Any ideas if this is possible via post_action or any other method?

The reasoning behind this is as follows:

We would in essence like to modify the users session (php, but the same concept can apply to most server side languages) while displaying cached content. This would greatly increase the number of cache-able requests we process since these requests only WRITE to sessions, not read from them.

Thanks!

We are using an nginx backend behind a nginx proxy.

We use upstream keepalives.

They work quite nicely.

We were wondering, what value would we set keepalive_requests on the backend to set the maximum number of keepalive requests to unlimited?

Thanks!

We have noticed that when using nginx internal 301 and 302 handling, nginx will serve a small document body with the appropriate Location: ... header.

Something along the lines of (in html): 301 redirect - nginx.

As appropriate in the above behaviour, a content-type text/html and content-length header is also sent.

We do a lot of 302 and some 301 redirects, the above behaviour is wasted bandwidth in our opinion.

Any way to disable this behaviour?

One idea that crossed our mind was to set error_page 301 302 to an empty text file. We have not tested this yet, but I am assuming even with the above, the content-type and content-length (0) headers will be sent.

So, is there a clean way to send a "body-less" 301/302 redirect with nginx?

We have the following url we would like to proxy cache:

file.php?parameter=one&paramater2=two&r=EPOCHTIMESTAMP

Query string parameter "parameter" varies between requests. So does "paramater2".

Query stringing parameter r is a timestamp we use to make sure the client doesn't serve cached (on the client side) content. Aka "cache buster". Yes we also use all the appropriate don't cache h headers.

Now, we would like to proxy cache via nginx some of these requests. Is it possible to instruct nginx to ignore the r querystring param but use all the others when setting a cache key for the entry? If we can't ignore param r then the nginx proxy cache will be useless as each cache key will be unique.

Thanks.

The title of this question is pretty self explanatory, but:

Does apaches keep alive timeout reset (as in, start again) every time a request is received?

So for example, assume we have a 60 second keep alive timeout:

Second 0 - First request recieved, keep alive starts - Timeout currently 60 seconds

Second 10 - Next request recieved, keep alive reset - Timeout currently 60 seconds

OR

Second 0 - First request recieved, keep alive starts - Timeout currently 60 seconds

Second 10 - Next request recieved, keep alive does not reset - Timeout currently 50 seconds

Thanks.

We are going to be running a nginx reverse proxy that will pull data from a backend via the internet.

What we mean by via the internet is the backend machine will not be on a lan with the front facing reverse proxy.

We were thinking it would be nice to grip these requests prior to sending them over the internet.

The way I see it it should work something like this:

Client requests content with a accept-encoding header or gzip.

Reverse proxy sends this to the backend server.

Backend compresses this content since a accept encoding header of gzip was sent.

Request sent all the way up the chain compressed.

This we can all do as its pretty straight forward. The question I have is how will this work if we have gzip compression enabled on the nginx reverse proxy side?

Will nginx try to gzip content that is already gzipped?

Hope this makes sense. Thank you.

UPDATE 1:

I understand the implications of caching already (and this serving) gzipped content. We would modify the cache key to include the accept encoding header, and thus serve (and cache) the properly compressed / uncompressed content according to what the user agent can accept.

We have recently upgraded our e1000e (intel ethernet) module on one of our CentOS 6.0 boxes.

Even tho the module compile and installed fine, the old version is still being used.

We have tracked this down to the fact that the e1000e.ko module is located inside the initamfs file for the booting kernel and thus, even tho the module located in /lib/modules/.... was being updated, the old one is still being loaded from inside the initramfs file.

After some research, we have found that creating a new initamfs file in CentOS should be as simple as:

/sbin/dracut <initramfs> <kernel-version>

Can someone confirm that this is a safe way to basically recreate the initamfs file?

This is a non-locally hosted (1000's of km away...) box, and getting support to resolve this if a reboot is unsuccessful will lead to quite a bit of down time.

Quite often, when reading about the recommended worker_processes for nginx it is stated that this should be set to the numbers of cores the server hosting nginx has.

We were wondering if we should count the number of HT cores for this as well?

Or do we just count the number of true physical cores?

Thanks!

I think starting with a small snippet would be wisest:

    location ^~ /test/ {
            proxy_pass              http://frontend;
            proxy_http_version      1.1;
            proxy_set_header        Connection "";
            proxy_set_header        Host $host;
            proxy_set_header        X-Real-IP $remote_addr;
            proxy_set_header        X-Real-Port $server_port;
            if ( $remote_addr ~* "123.123.123.123" ) {
                    proxy_cache            cache_base;
                    proxy_cache_valid      720m;
            }
    }

So, in essence what we want to do is setup proxy caching based on a coniditonal IF statement.

The above does not work, as proxy_cache is not valid inside IF.

Does anyone know how to proxy cache based on a regexp match on one of the many nginx internal variables?

Note:

We want to basically disable / enable proxy_caching based on $remote_addr regexp. Not specify different proxy_cache values.

Thanks.

With nginx, latest, is it possible to proxy cache ONLY specific html status code responses?

We use 410 status codes for some responses.

These are checked against our database.

When the said content is flagged as removed for ever (410), a 410 status code is sent.

This content is gone forever.

We would like to proxy cache ONLY these results.

Is this possible?

We have just setup a lovely little nfs share / client for the first time.

a) The UID for files on the client side, is showing up as 4294967294 when listed via ls, but the client is able to create and remove files / dirs in the share. Files and folders created on the client end, show up with the correct username (and uid) on the server side. We made sure that the users writing to the share have the same UID on the server end.

The following shows up for all files / folders on the client side:

drwxr-xr-x 6 4294967294 4294967294 4096 Feb 23 16:04 foldername

Is this ok?

b) Does anything need to be done with portmap / the nfs daemons to completely disable any nfs (or rpc*, as it was not installed prior to this) services from running on our external interface? Ideally we would like to bind the services just to our lan and vpn subnets.

c) What is the ideal way to make the nfs client side as aggressive as possible on reconnection attempts? Ideally, if the network connection is lost at any time, the nfs client side would keep trying often, and indefinitely. Is it possible to accomplish this via fstab? Or does nfs client by default already do this? The LAN side, where the nfs shares are shared, is a 1GBit connection.

d) Anything else?

Over and out.

We have a couple of complex virtual host definitions in our httpd.conf file.

What I mean by that is:

<VirtualHost .....>
....
</VirtualHost>

What I mean by complex is that they are full of rewrite rules and such.

We would like to bind this virtual host on 2 ip addresses. Currently it is bound only to one.

Is it possible to bind a virtual host to 2 ip addresses using a single VirtualHost?

It would make things a lot easier to have a single one if we need to make changes in the future.