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;

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).

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:-) ).

Just been going trough a lot of reconfiguration lately and today finished configuring a new server. While testing the mail function we saw in the mail logs the following lines:

javax.mail.MessagingException - 501 Syntactically invalid HELO argument(s)

First we thought, it is the application server or sendmail/exim not being properly configured. But as we soon found out, one simply needs to have a valid hostname set for the server. In other words, this error is commonly caused by the hostname of the machine being wrong compared to what the mailserver expects. Java mail does a getHostName and uses that in the HELO.

And just in case you simply set your hostname with “hostname domain” it will not persist on the next reboot. In order to keep your new hostname you will need to change it in the hostname file itself, as in:

sudo  vi /etc/hostname

Do a reboot and all should be good.

CentOS, being a “legal copy” of RedHat, as good as it is, comes with some really outdated libraries. This has caused many, including myself, to find way how to bring latest code releases into CentOS. Be it by alternatives repros or compiling the packages.

Now, I don’t know how I could overlook it, but I just found out that the CentOS team offers a CentOS-Testing repro. Once installed you will get the latest library updates as well. Since it is based and supported by the CentOS guys, I figure it is the safest way to get the latest updates.

Simply add the following at /etc/yum.repos.d/centos-test.repo:

[c5-testing]
name=CentOS-5 Testing
baseurl=http://dev.centos.org/centos/5/testing/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing

Save it and do a yum check-update and you will get all the good yummies. Make sure that you don’t install something carelessly on a production server, right…

Running an Oracle database is great, because it is stable and just runs, but sometimes you are hit with unexpected errors when you restart your machine. Thought, I know Oracle quite well, I’m always surprised at some things. Here are two errors (and solution) I was just confronted with:

ORA-27101: shared memory realm does not exist

To be honest, I don’t know why I was confronted with this error, since we haven’t changed anything to the machine or to the environment variables. Metalink suggest to check that the ORACLE_HOME and ORACLE_SID are correct. Funny thing is that this system runs for over a year without a change to the path, nevertheless I checked the ORACLE_HOME path and sure enough I had trailing slash at the end.

So, the solution was to see that ORACLE_HOME does NOT have a trailing slash.

echo $ORACLE_HOME
/opt/oracle/product/11/ <--- WRONG!

echo $ORACLE_HOME
/opt/oracle/product/11 <--- CORRECT!

Remember to log out of your current shell session in order to reapply the new settings.

ORA-28002: the password has expired

Now, this error caught be even worse, because it happened right within a production environment. Also, here I was unaware of this setting. In any case, Oracle seams to want you to reset your password after one year or so. In case, you want to disable this on a user without changing the users password you need to issue the following commands in sqlplus:

alter profile {user} limit password_verify_function null;

This will set the verification for this user to null. If you want to do this for every user in your system you would use this (this is applied to the DEFAULT profile):

alter profile DEFAULT limit password_verify_function null;

Once done you can then reset the password for the user with the same password or with another one with:

alter user {user} identified by {password};

Exit sqlplus and your changes should have been applied.

I had to spent way too much time the last time to set up ImageMagick and Ghostscript together that I simply jump right in so you don’t have to waste time on this, like I did.

Creating thumbnails and images from a PDF is one of the most used features within Razuna. But the other day, when we run the normal convert command we were faced with an error message within our web application of:

Error: Uncaught exception ‘ImagickException’ with message ‘Postscript delegate failed....: No such file or directory

Of course, the first thing I did was to see if we have a error in the shell. Strangely, there was NO error when running the same command in the shell! Needless to say, I spent many hours looking for a solution, trying out different things from reinstalling ImageMagick and Ghostscript to looking all over the web for an answer.

In the end, it boiled down to that web applications (be it CFML, PHP, etc.), are looking for a different executable path then when you run command from the shell. Since Ghostscript installed the executable in the “/usr/local/bin/gs” path the web application could not find it. So the solution to “hours of pain” was to simply create a symbolic link to the “gs” library in the “/usr/bin” directory with:

ln -s /usr/local/bin/gs /usr/bin/gs

Hope this helps the next seeker!

My two other posts on FFmpeg entitled “Installing ffmpeg on CentOS 5” and “SELinux with ffmpeg” already explained in deep how to get FFmpeg up and running.

Unfortunately, today one of our servers just reported a plain:

ffmpeg: error while loading shared libraries: libfaad.so.0: cannot open shared object file: No such file or directory

when trying to run any ffmpeg command. Now, what was that and foremost why? Especially, since it worked 2 days ago. I guess, “someone” must have done some update. In any case, it was a good lesson to reinstall ffmpeg and bring all libraries up to date.

So, since my last installation, some things must have obviously been changed behind the scenes, because when I tried to configure ffmpeg with the same commands I run into another error which was:

libx264 version must be >= 0.78

Even thought I installed x264 from the latest GIT repository it still showed me the above error! Looking around the Videolan.org website I saw that the nightly snapshots differ in size a lot. So, either their nightly script is broken or something else is going on. In any case, I went with the x264-snapshot-20091031-2245 one.

Configured and installed it. Then did a “ldconfig -v” (in order to see that it really took the latest one) and went on with the ffmpeg configuration (I took the latest code from SVN (Revision 20525)) and low and behold, everything compiled and installed without problem.

Important: Update your libraries after the installation of ffmpeg again with “ldconfig”! Else you will get the “ffmpeg: error while loading shared libraries: ….” error again.

My favorite choice for running a Linux Server is CentOS, since it is based on the RedHat distribution you can rest assured you will get a top notch enterprise offering and stability. As with all things “enterprise” the priority is on stability and security and not on the latest code releases. This works 99% of the time, but sometimes you still need some update.

In the case of ImageMagick, CentOS comes with version 6.2.8, it was a bug that was fixed with PSD conversion and thus I needed to get the latest version installed. So, here are the steps to install ImageMagick 6.5.7 on CentOS 5.x. Mind you, that you will loose the internal patch upgrading from yum, but all you need to install to the next version is just to follow these steps again.

Uninstall current version
Uninstall the current version with:

yum erase ImageMagick*

This will uninstall ImageMagick 6.2.8 and if you have any other versions installed, like the devel one.

Install the needed dependencies
ImageMagick depends on a couple of additional libraries to convert to different formats. Let us just make sure, that they are all installed with:

yum install tcl-devel libpng-devel libjpeg-devel ghostscript-devel bzip2-devel freetype-devel libtiff-devel

Download and extract latest ImageMagick version
You can always get the latest ImageMagick version directly from their website. Code below will download and extract the file.

wget ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick.tar.gz
tar xcvf ImageMagick.tar.gz
cd ImageMagick-6.5.7-5

Configure and make ImageMagick
With the below configure command we are configuring ImageMagick with the most needed options. Feel free to adjust it to your needs. As always issue a “–help” to see all the available options.

configure --prefix=/usr/local --with-bzlib=yes --with-fontconfig=yes --with-freetype=yes --with-gslib=yes --with-gvc=yes --with-jpeg=yes --with-jp2=yes --with-png=yes --with-tiff=yes

Wait until configure has finished. At the end you will see all the enable options. When you think all went well issue:

make

Now is a good time to make yourself some coffee or continue coding your next big killer application because make will take some time to finish. When it’s done, issue:

make install

That’s it! You are done. Wasn’t so bad, was it? Check with:

convert --version

That ImageMagick is properly installed and that you got the current version up and running. If all went well you should see something similar to this:

Version: ImageMagick 6.5.7-5 2009-11-08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2009 ImageMagick Studio LLC

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′