[TYPO3-dam] dam_index external tools

[georg kuehnberger]

Ahoi Xavier, Francois,

I feel it makes sense to focus on the TYPO3 & DAM perspective, without 
digging deeper into the php config-options / restriction / 
versions-stuff (as this is pretty much out of the TYPO3-Scope anyway).

IMHO:
- TYPO3 should have an API-function within the core that allows any 
Extension to simply checks for existance and executability of any needed 
external program.
- All Extensions should use call up this function before executing the 
external program configured.

I don't know by heart wether this IMHO needed API-function + it's usage 
is part of the TYPO3 API documentation; in case NOT in the docu please 
contribute to it.

In case more than one API-functions for that purpose are existing, 
please contribute by suggesting a streamlined version or recommended one.

So, in case it's the way, that a check and subsequent extecution a 
binary works in one extension (you mentioned indexed_saerch), and dioes 
not work from another extension (whatever dam-service), apperently the 
"another extension" is not using it in the right way and has to be 
fixed; yet another option to contribute.

As for the rest I'm fully with Francois, especially in regards to the 
open core-list.

And I'd like to add:
This little virtual universe is highly similar to the offline world:
- sometimes people are to busy to answer / discuss,
- often people simply dont understand the question,
- and even more often people simply dont know the answer.
All of the above leads to "no echo"; so I recommend to re-send the same 
question earliest 14-days after your initial unanswered question; by 
then the above situation might have changed;

Hope this helps an thanks for your offer to contribute to the project;
'njoy TYPO3
regards georg



Xavier Perseguers wrote:
> Georg,
> 
> Thank for your answer, I thought nobody would answer me :-)
> 
> I decided to track this problem down, wherever it would get me and 
> finally got the answer:
> 
> 1) I use openbase_dir restrictions in php.ini and I forgot to include in 
> the list my special directory holding binaries TYPO3 is allowed to 
> execute (not the standard /usr/bin/). As the is_dir() function is used 
> to check for invalid paths in t3lib/class.t3lib_exec.php, I got a 
> "openbase_dir exception" that leaded to invalidate my special bin 
> directory as a valid directory to be searched for external tools
> 
> 2) My TYPO3 binary directory is a set of external tools such as 
> pdftotext, exiftags, unzip, ... that are *symbolic links* to the real 
> executable that mostly rely in /usr/bin. Problem is that 
> t3lib/class.t3lib_exec.php tries to find out if the configured tool is 
> executable, leading to invalidate any symbolic link to /usr/bin as 
> openbase_dir restriction is again in action.
> 
> My conclusion is as follows:
> 
> 1) the tests in both classes I described above and located in t3lib_dir 
> do checks using the "@" prefix to functions is_dir() and 
> is_executable(). That is any warning (such as the openbase_dir 
> restriction) will not be put in the PHP error log. I think this is a 
> problem that should be tackled with as it is complicated to track down 
> such issues.
> 
> 2) A better check should be used as openbase_dir just works fine with 
> the same external tools when used in extensions such as indexed_search.
> 
> 3) I cannot hard link to these tools as my web space is stored on 
> another disk partition and whenever I choose to copy those external 
> tools to my dedicated bin directory, I'll have to manually take care of 
> any update to them.
> 
> May I contribute to enhance this base class? Do someone disagree with my 
> point of view? And if so, why?
> 
> PS: I'll cross post this to the English list as the discussion (in fact, 
> just my post) started there.