Tag Archives | error message

Nginx error with Tomcat – upstream sent too big header while reading response header from upstream

Nginx is our favorite web server currently as it is fast, lean and easy to configure. Performance is just outstanding and if you haven’t take a look at it.

One thing that I noticed while we deployed Nginx with Tomcat is that their default size for the buffers are very low. Don’t know why a 4K buffer size would be sufficient. If you keep it at their default size and might have a heavy duty Tomcat app then it could be that you will see error messages like:

upstream sent too big header while reading response header from upstream

The remedy for this error is to set the parameters for higher values for the proxy_buffer* parameters as we have done and now all is back to normal. Here are the current settings that worked well for us;

proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;

Comments { 835 }

SugarCRM: Inbound eMail

SugarCRM is a good open source CRM, but the overwhelming functions and navigation makes it “sometimes” hard to really get to the one thing you want to do. In any case, it does the job well. Apart from that, I just came upon this error message within SugarCRM:

Warnings: Inbound Email cannot function without the IMAP c-client libraries enabled/compiled with the PHP module. Please contact your administrator to resolve this issue.

This definitely means that PHP is missing some mail libraries, but the message to compile PHP is kinda scary, isn’t it? Luckily, if you are using Ubuntu all you need to do is to issue an “apt-get” command and you are rolling. So here we go:

apt-get install php5-imap

This will install everything for you, make sure to restart PHP (restart Apache or the FastCGI).

Comments { 784 }

Nginx, Apache, SSL and signed by an unknown certifying authority

We just moved a whole bunch of servers to a new hosting center and moved from CentOS to Ubuntu (server) and Apache to Nginx (more on this in a later blog post).

While we migrated mostly everything without problems we were confronted with the problem that our SSL certificate gave us an error message of the form:

“The certificate for this website was signed by an unknown certifying authority”

This was rather strange because the same certificate worked with Apache just fine. After some time and searching for a solution we found that we had to tell Nginx to use the SSL Chain file as well. The only problem is that Nginx does not have a explicit parameter like Apache has. In Apache the SSL config looks like this (we use a GoDaddy certificate):

SSLEngine On
SSLCertificateFile /etc/httpd/ssl/youcert.crt
SSLCertificateKeyFile /etc/httpd/ssl/yourkey.key
SSLCertificateChainFile /etc/httpd/ssl/gd_bundle.crt

Now, in order to get this working in Nginx you need to append the “gd_bundle.crt” to your crt file, which is quite simple with the following commands (do a backup of any files before doing this!):
cat gd_bundle.crt >> yourcert.crt

Then simply restart Ngnix and all is back to normal (but just really faster with Nginx then with anything else:-) ).

Comments { 1,021 }

SELinux and FFMpeg

SELinux is a good thing, but it also requires you to watch out on some libraries. Sometimes, something just fails, because SELinux does not allow it to run. This so happens when you have SELinux installed and want to run FFMpeg.

I just run into this when I tried to run FFMpeg and got this error message:

“error while loading shared libraries: /usr/lib/libavcodec.so.52: cannot restore segment prot after reloc: Permission denied”

In order to run FFMpeg without problems I had to add the remove the restrictions for SELinux with:

chcon -t textrel_shlib_t ‘/usr/lib/libavutil.so.49.15.0′
chcon -t textrel_shlib_t ‘/usr/lib/libavcodec.so.52.20.0′
chcon -t textrel_shlib_t ‘/usr/lib/libavformat.so.52.31.0′
chcon -t textrel_shlib_t ‘/usr/lib/libavformat.so.52.31.0′
chcon -t textrel_shlib_t ‘/usr/lib/libswscale.so.0.7.1′

Comments { 675 }