Handling the "open() 11 resource temporarily unavailable" error with nginx (samba problem)

If you happen to edit your files through samba and serve them with nginx you may get some "11: Resource temporarily unavailable" which are originated by the fact that nginx cannot open the file in question.

Samba performs a lock to the file you're editing and I don't know exactly how nginx open the files it's serving, but the problem is that Samba locks the file nginx is trying to read.

So, a bit of searching through the locking options with Samba and I found out an option to put in smb.conf that solves the problem:

oplocks = no

This option enables or disables support for oplocks on the client. The option is enabled by default so we're turning it off.

Restart Samba and you should not get more open() errors.

Carlos

Dump an strace log to a file

I wanted to strace a php backend to see if the X-LIGHTTPD-send-file header (and feature) of Lighttpd was actually working, so I could see the backend doing some read operations or not and prove that the php was not in fact the process sending the file.

This was not necessary at all, but I just wanted to confirm php REALLY not having anything to do with the downloads.

So I started strace with the PID of the backend and saved the log to see those open() and read() operations

strace -Ff -tt -p PID 2>&1 | tee strace.log

And that was pretty much it ;-)

Paypal IPN listener security (without validating Paypal's IP address pool)

I found a way to not check the source (IP address) of the IPN messages Paypal sends to my IPN listener so I can prevent spambots and fake postings to it.

When you build your DoExpressCheckoutPayment request (or other requests that may set the IPN NOTIFYURL), set the NOTIFYURL to something like:

PAYMENTREQUEST_n_NOTIFYURL=https://YOURHOST/?ipn_secret=yoursecret

Paypal then send you an IPN message with the POST method, but in the URL (and consequently in your $_GET variable), it will include your secret variable (ipn_secret in this case) that you can check to match.

As the DoExpressCheckoutPayment request went through HTTPS (SSL secured) you can be sure only Paypal and you knows the ipn_secret value.

This way you can avoid checking that the message came from an authorized source (and by source I mean their IP address pool, which they can change at any time without notice).

Of course, you still have to reply the exact message you received in the same order and wait for the VERIFIED or INVALID strings, but by doing this you can avoid to connect to their servers each time you get a fake message from someone who is NOT Paypal (spambots and the like) preventing a denial of service on your server because you HAVE to connect and send the message to validate it.

Hopefully this will help someone, since I didn't saw anything in the IPN documentation or the forums regarding this issue.

Carlos