Installing FOP2 in wheezy
There is no libcrypto.so.0.9.8, just libcripto.so.1.0.0. A soft link is not working either.
The funny thing is I'm trying FOP2 because I've installed Debian Wheezy because I wanted Asterisk 1.8 and FOP does NOT work well with Asterisk 1.8.
Starting Flash Operator Panel 2: fop2Can't load '/tmp/par-root/cache-blablabla/blabla.so' for module Filter::Crypto::Decrypt: libcrypto.so.0.9.8: no se puede abrir el fichero del objeto compartido: No existe el fichero o el directorio at /usr/lib/perl/5.8/DynaLoader.pm line 225.
at /usr/local/share/perl/5.8.8/PAR/Heavy.pm line 128
BEGIN failed--compilation aborted at /tmp/par-root/cache-blablabla/inc/lib/Filter/Crypto/Decrypt.pm line 37.
Compilation failed in require at script/fop2_server.pl line 1.
BEGIN failed--compilation aborted at script/fop2_server.pl line 1.
When a softlink is created, this error appears:Starting Flash Operator Panel 2: fop2Can't load '/tmp/par-root/cache-blablabla/blabla.so' for module Filter::Crypto::Decrypt: /usr/lib/libcrypto.so.0.9.8: version `OPENSSL_0.9.8' not found (required by /tmp/par-root/cache-blablabla/blabla.so) at /usr/lib/perl/5.8/DynaLoader.pm line 225.
at /usr/local/share/perl/5.8.8/PAR/Heavy.pm line 128
BEGIN failed--compilation aborted at /tmp/par-root/cache-blablabla/inc/lib/Filter/Crypto/Decrypt.pm line 37.
Compilation failed in require at script/fop2_server.pl line 1.
BEGIN failed--compilation aborted at script/fop2_server.pl line 1.
The funny thing is I'm trying FOP2 because I've installed Debian Wheezy because I wanted Asterisk 1.8 and FOP does NOT work well with Asterisk 1.8.
Comments
I am sorry for the delay in approving your post. I did not want to leave it open without a consistent reply and solution.
As you find out, debian wheezy includes a libcrypto and more importantely an openssl library that are a couple of versions ahead of the ones FOP2 expects, so the symlink is not enough.
But as we tried today, having a static linked libcrypto on the fop2 binary worked ok, so I believe that in the next versions that library will be statically linked (after I test it in other platforms and distributions).
And now my opinion: if you want to run Asterisk in production, you might want to use a stable distribution, if you go cutting edge, you might experience some issues that are perhaps not present in a "stable" distribution. Remember that "testing" debian releases do not include security fixes or control, so I would stay away myself from it for a production server.
Best regards,
I'm upgrading old servers and it's taking so much to roll up every upgrade that putting myself a little over the edge seemed not a bad idea.
I've installed it in my computer in february to feel what was going on in testing and I've measured the amount of updates per month and how strong the changes were: library changes, version shifts. It's something bearable.
It is not bad to stay current. Actually, you are really brave! If you are testing, then all is well, but if you are going to put that box into production, I would think it twice myself. Mostly because security updates are not handled in a timely manner in any debian testing version.
Lets go back just to Asterisk: If you want to install Asterisk 1.8 it is not hard to do it from sources. If you want to be really cutting edge, you should install Asterisk 10 instead. Installing asterisk from package (either rpm or deb files) will have you exposed to sometimes severe security risks/problems, and more often than not, with an outdated asterisk version. There are perhaps one or two security advisories per month in asterisk itself, but there are no deb or rpm package that updates that quickly. And some of the advisories are serious, that could let your machine exposed to DDOS attacks, an easier target for sip dictionary attacks, etc. VOIP fraud is rising, and it costs a lot of $$$ if you get hit. It will really hurt your bottom line (not like a script kiddie defacing a web site).
There are also a lot of cool addons for Asterisk that requires you to install Asterisk from sources. Many many times I find customer boxes that were installed via rpm, but then "upgraded" via source files and it all becomes quite a mess. That is why *I* prefer distros that compile asterisk from source instead of distros that package it in any way, because the world move faster that package managers.
Your findings were beneficial to FOP2, as it will help get the package ready for the future, and I really appreciate your detailed post and information. But let me express my opinion again: use wheezy in your lab or test setup, but *I* would not put it into production or exposed to the internet.
My Asterisk servers are not public. None of them, and I take the time to install anything new... man, I'm breaking my head on this one...
I'll try to compile with Squeeze. If I'm going on that path, I need to create an automated way. Packages are a safe way to stay current.
Do whatever you want, I was just expressing my opinion based on my experience. You do not have to take my word/advice. You seem to be a seasoned linux user and I am sure you can administer wheezy systems and update them on time.
We already worked it out, and fop2 is now working on wheezy when statically linked with libcrypto. The fop2 package is a little larger this way, but it solves the issue when using the latest and greatest openssl and libcrypto libraries. This very same thing can be done on Centos packages to avoid having to create symlinks on Centos 6.
Best regards,
Sorry for my bad english, but i solved problem on deb wheezy i386.
Profit! 8-)