Re: [Postfixadmin-devel] Blank domain.tld/setup.php page nothing in logs

[Christian B. <pos...@cb...>]

Hello,

sorry for the late reply, but I'm running out of ideas...

That said, maybe we should switch to the crazy ideas ;-)

Am Dienstag, 12. März 2019, 00:23:54 CET schrieb Danny Houtworm:
> On Mon, 2019-03-11 at 23:10 +0100, Christian Boltz wrote:
> > This indicates that require_once() can read config.inc.php.
> > 
> > To confirm that, please introduce a syntax error in config.inc.php,
> > and
> > then run setup.php on the commandline again. You should see a
> > message
> > about that syntax error.
> 
> I added some gibberish to the config.inc.php file and i indeed get a
> Syntax errors :)
> 
> [houtworm@server ~]$ sudo -u http php
> /usr/share/webapps/postfixAdmin/public/setup.php
> PHP Parse error:  syntax error, unexpected 'ik' (T_STRING) in
> /usr/share/webapps/postfixAdmin/config.inc.php on line 17
> [houtworm@server ~]$

OK, so config.inc.php is readable and gets included, and "only" the 
check fails for some strange reason.

Repeat that test with config.local.php to ensure it also gets used.

> > One idea I have is the way how setup.php checks for
> > config.local.php:
> >     $file_config = file_exists(realpath("./../config.inc.php"));
> >     
> >     $file_local_config =
> > 
> > file_exists(realpath("./../config.local.php"));
> > 
> > Note the realpath() call, which means resolving all symlinks.
> > Does the path /usr/share/webapps/postfixAdmin/public/ include any
> > symlinked part?
> 
> In /postfixAdmin only .htaccess is symlinked
> 
> in /public only password-change.php and password-recover.php are
> symlinked
> 
> The config files where both symlinked because i copied local from inc,
> i removed both and made new files for them to ensure they are not
> symlinked. I did this before but it did not help, Maybe the inc file
> needs to be symlinked?

There's no requirement that config.*.php has to be a symlink (but having 
them as symlink can be useful so that you can have the actual files in 
/etc/postfixadmin/ - that's nice for distro packaging and being FHS 
compliant)

> > If in doubt, add
> > 
> >     echo "\n\n file_config: $file_config  local $file_local_config
> > \n\n"
> > to setup.php (directly under the lines quoted above) and check the
> > result.
> 
> I edited it like this /usr/share/webapps/postfixAdmin/public/setup.php
> 
> 56 $file_config = file_exists(realpath("./../config.inc.php"));
> 57 $file_local_config =
> file_exists(realpath("./../config.local.php")); 58     echo "\n\n
> file_config: $file_config  local $file_local_config 59 > \n\n";
> 60 $error = 0;
> 
> terminal output
> 
> [houtworm@server ~]$ sudo -u http php
> /usr/share/webapps/postfixAdmin/public/setup.php
...
>  file_config:   local

So both variables are False/empty which means that file_exists() thinks 
the files don't exist.

Let's try some more debugging code (add it at the same place):

echo "\n realpath of config files:\n";
echo realpath("./../config.inc.php");
echo "\n";
echo realpath("./../config.local.php");

> Then finding that file is the only thing that matters, Very strange it
> does not see it.

Well, the fact that introducing a syntax error  triggers an error means 
that the code finds the config files, but the checks in setup.php don't.

There might be a crazy "fix": adjust setup.php and change

$file_config = file_exists(realpath("./../config.inc.php"));
$file_local_config = file_exists(realpath("./../config.local.php"));

to

# fake test results
$file_config = True;
$file_local_config = True;

This will obviously avoid the test failure, but since we know that the 
config files get included successfully, it's worth a try ;-)


Regards,

Christian Boltz
-- 
For patterns and products, this is - as we now learned - wrong and
confusing.  (We will probably have more such learning effects in the
future ... ;-})
[Klaus Kaempf in https://bugzilla.novell.com/show_bug.cgi?id=198379]