At last, I've been able to figure out where the pipe() problem stands. 389-admin is improperly using the cgi module. When using a multithreaded MPM (worker), mod_cgid had to be used. It happens that 389-admin needs apache (with worker MPM) and mod_cgi (and not mod_cgid). mod_cgid fork() itself from the main httpd process while mod_cgi doesn't. That's why password_pipe() works fine with the latter. Unfortunately, when you tell the build system that you want to use the worker mpm, it completely ignores your request (via --enable-cgi switch) of using mod_cgi (instead of mod_cgid) and always builds mod_cgid (despite the .so is called mod_cgi.so). In binary distributions that over-split packages, both apache#worker and apache#prefork are built separately and so their modules. This makes possible to install mod_cgi into a system that is using apache#worker, otherwise impossible (when building from sources). So, this masks the issue above in a perfect and (sadly) elegant way. Besides, this also explains why I was getting Scriptsock socket path conflict between mod_cgid and mod_restartd. See /etc/dirsrv/admin-serv/httpd.conf around line 395 (http://pastebin.com/f0K49cL5). Only mod_cgid uses that directive. Unfortunately (or fortunately) the potential directive error was masked by the fact that mod_restartd uses the same directive name, so if mod_cgid is not loaded, the line, from a config POV, is still valid. I think 389-ds should either do: - fix the pipe() issue (finding an alternative way of sending password data over) and let use apache#worker in a proper way (with mod_cgid as per docs -- http://httpd.apache.org/docs/2.2/mod/mod_cgid.html): best option from code quality POV - find a way to force building apache#worker with mod_cgi (worse option) Yeah, that is the final puzzle :-) Regards, -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
