exec FFmpeg as PHP/apache user

It's a fresh installation of version 2.2.7 (build 1010)
I don't have a www-data user, just apache.
which ffmpeg is pointing to /usr/local/bin/ffmpeg
sudo -i -u apache returns 'the account is currently not available'.

Which operating system do you use?
Maybe your user is apache, but you don't have rights to log in. You can check your etc/passwd file. If the last parameter gives back false (eg. /bin/false), then you can't log in.

The OS is RedHat Enterprise Linux (rhel), the apache user cannot login (/sbin/nologin).

Tom, any development?

No developments, I might have to change all references to ffmpeg with a full path...

I have the same problem - I've downloaded the current FFMPEG SVN-version, patched it with the current MM patch from SVN, compiled the whole with make and installed it as an official deb package with checkinstall. FFMPEG is recognised by the Ubuntu software center resp. package manager as "installed" - but not by the Mediamosa installation script!

So where should the FFMPEG reside in order to be recognized by the installation script and the status check?? (currently it's in /usr/local/bin)

You can try the following:
Go to your MediaMosa installation, then profiles/mediamosa_profile/mediamosa_profile.profile file.
Search ffmpeg (around link 280), and comment that out.

After the installation you can do a test upload / transcode to see ffmpeg works fine or not.
Then we will see, whether ffmpeg detection is wrong, or ffmpeg is not available.

I fixed this by adding a symlink ffmpeg in /usr/bin which points to /usr/local/bin/ffmpeg.
Turned out /usr/local/bin is not on the path of user apache and /usr/bin is. Now the status screen is green.
As root in/usr/bin execute: ln -s /usr/local/bin/ffmpeg

Thanks for this tip, Tom. Defining a symlink in /bin or /usr/bin would have been my next attempt, too - good news that this will definitely fix the problem!!

Just to inform others with similar problems:

Creating a symlink in /usr/bin and some other directories didn't solve the FFMpeg problem in my installation. Checking the error.log of the apache revealed that the libgcc_s.so.1 in /opt/apache/lib was the reason:
"ffmpeg: /opt/lampp/lib/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/i386-linux-gnu/libstdc++.so.6)"

So I removed this outdated version of the library and replaced it by a symlink to the up-to-date version in /lib, and after that everything worked fine!

Greets,

Dietmar

I am currently in the process of setting up a test installation of MediaMosa for the University of Oslo, Norway. We run Red Hat Enterprise Linux 6 server, with SELinux set to enforcing.

When compiling ffmpeg, everything run smooth with the following configuration:
yum -y install libtheora-devel libvorbis-devel gsm-devel schroedinger-devel openjpeg-devel libdc1394-devel

./configure --enable-libdc1394 --prefix=/usr --enable-shared --enable-gpl --enable-libvorbis --enable-pthreads --enable-libgsm --enable-libtheora --enable-nonfree --disable-stripping --enable-libschroedinger --disable-encoder=libschroedinger --enable-avfilter-lavf --enable-libopenjpeg --enable-version3 --disable-altivec --disable-armv5te --disable-armv6 --disable-vis

Using this configuration, ffmpeg works for all users. However, it stopped working when I added the following options (which I have compiled and installed as well):
# --enable-libmp3lame
# --enable-libfaad
# --enable-libfaac
# --enable-libmp3lame
# --enable-libx264

The solution:
If I exported the LD_PATH to the libraries, everything seemed to be working, so by first
export LD_LIBRARY_PATH=/usr/local/lib64/
and then
sudo -u apache ffmeg

things were working. However, exported paths only "live" for one session, so the final solution was to add the following:
echo "/usr/local/lib64" >> /etc/ld.so.conf.d/usr_local.conf
ldconfig

Sidenote
In some of the early tests we did, ffmpeg was looking for libraries in all the wrong places, which can easily be rectified with a symlink or two - like so:
ln -s /usr/local/lib/libfaad.so.2 /usr/local/lib64/libfaad.so.2
ln -s /usr/local/lib/libfaad.so.2.0.0 /usr/local/lib64/libfaad.so.2.0.0


If you are still having trouble, please inspect /var/log/messages and look for selinux-alerts:
grep sealert /var/log/messages

Config-files used by Apache, will need proper context.

Hope this is of help. If it is of interest, I have documented the entire installation process on how to install and run MediaMosa on RHEL6 Server with SELinux enforcing. Just give a shout!

--
Håvard Hvassing

Håvard, Thanks for the solution.
Yes, of course, it would be very interesting, if you have documentation about the installation process on RHEL6 Server.
If you send it, we will put it to the wiki pages.
Peter F.

Håvard,

Thank you.
The wiki page was created:
http://mediamosa.org/trac/wiki/Installing%20MediaMosa%202.3.x%20on%20RHE...

Hi again,

some codecs and modules related to ffmpeg put their libraries in odd places, meaning that MediaMosa via Apache can't successfully start ffmpeg.
We've solved this with a workaround using a wrapper script that first exports all paths needed, then calls on ffmpeg.

which ffmpeg
> /usr/bin/ffmpeg

mv /usr/bin/ffmpeg /usr/bin/ffmpeg-bin
touch /usr/bin/ffmpeg #The ffmpeg wrapper bash script
chmod a+x /usr/bin/ffmpeg

Now, add this to your wrapper script, remember to add/remove paths as needed:
#!/bin/bash

# Export all necessary variables in order for
# ffmpeg to find all libraries needed

export LD_LIBRARY_PATH=/usr/local/lib64/:/usr/local/lib/:/usr/bin/:/usr/lib/:$LD_LIBRARY_PATH

# The ${0##*/} thing means $0 with anything coming before a slash, including
# the slash chopped off. Since $0 contains the application’s name as it was
# called, ${0##*/} is the application name without the path
# Source: http://billauer.co.il/blog/2010/01/wrapper-xilinx-ise-fc12-library-hijack/

exec /usr/bin/${0##*/}-bin "$@"

Hope this proves useful