Cidram: No log generated

[szemet]

It started a while ago, with v1, but no change after upgrade to v2.
In the config.ini, the relevant line is _logfile='/log/{yyyy}-{mm}-log.txt'_ but this worked even before the logging stopped working.
Tried with a simple _logfile='log.txt'_ and with the full dir path on the host, but no change.
The php error log is empty.

The statistic page works.

This is a shared hosting with PHP version 7.2.34 and CIDRAM version 2.5.2-DEV+21103596.

[Maikuolan]

Hi szemet,

Mind checking for me, what permissions or CHMOD settings are assigned to CIDRAM's vault directory? Is it writable?

Cheers.

[szemet]

The vault, the log and the cidram basedir is 755. It's writable, modifying the config file and the update both working perfectly via the frontend.

edit: I did a reinstall (only the config.ini copied over) and no change

[Maikuolan]

Cheers. Tested the specified settings at my end, but didn't encounter the same problem. Still trying to replicate it though.

At the front-end updates, there should be an option to "verify all". Mind clicking on that, and let me know whether any "Verification failed! Component could be corrupted." messages appear? Clicking that button with compare the hashes of CIDRAM's files against those it expects, to confirm whether there's any mismatches, plus perform some very rudimentary sanity checks against whatever components are installed. Generally, if all the hashes match as expected, and if all the "sanity checks" pass, everything should show as "Verification success! No problems found." Otherwise, if it detects any mismatches, or if any of the "sanity checks" fail, it'll show "Verification failed! Component could be corrupted." for the components affected (that can occur sometimes if something doesn't update properly, or if there's something on the system tampering with files, etc).

[szemet]

Thanks.

_Verification success! No problems found._ for all files:

module_cookies.php – Verification success! No problems found.
module_extras.php – Verification success! No problems found.
module_baidublocker.php – Verification success! No problems found.
module_yandexblocker.php – Verification success! No problems found.
module_badtlds.php – Verification success! No problems found.
module_sfs.php – Verification success! No problems found.
module_botua.php – Verification success! No problems found.
Chart.js – Verification success! No problems found.
flags.css – Verification success! No problems found.
module_abuseipdb.php – Verification success! No problems found.
module_bgpview.php – Verification success! No problems found.
CN_cidram.inc – Verification success! No problems found.
KR_cidram.inc – Verification success! No problems found.
aws_cidram.inc – Verification success! No problems found.
aws_cidram_ipv6.inc – Verification success! No problems found.
cfrp_cidram.inc – Verification success! No problems found.
cfrp_cidram_ipv6.inc – Verification success! No problems found.
cldbyp_cidram.inc – Verification success! No problems found.
msaz_cidram.inc – Verification success! No problems found.
tpbm_cidram.inc – Verification success! No problems found.
CIDRAM Core – Verification success! No problems found.
CIDRAM Front-End – Verification success! No problems found.
Common Classes Package – Verification success! No problems found.
IPv4 – Verification success! No problems found.
IPv4-Bogons – Verification success! No problems found.
IPv4-ISPs – Verification success! No problems found.
IPv4-Other – Verification success! No problems found.
IPv6 – Verification success! No problems found.
IPv6-Bogons – Verification success! No problems found.
IPv6-ISPs – Verification success! No problems found.
IPv6-Other – Verification success! No problems found.
Bypasses – Verification success! No problems found.
l10n/en – Verification success! No problems found.
l10n/ar – Verification success! No problems found.
l10n/bn – Verification success! No problems found.
l10n/de – Verification success! No problems found.
l10n/es – Verification success! No problems found.
l10n/fr – Verification success! No problems found.
l10n/hi – Verification success! No problems found.
l10n/id – Verification success! No problems found.
l10n/it – Verification success! No problems found.
l10n/ja – Verification success! No problems found.
l10n/ko – Verification success! No problems found.
l10n/lv – Verification success! No problems found.
l10n/nl – Verification success! No problems found.
l10n/no – Verification success! No problems found.
l10n/pl – Verification success! No problems found.
l10n/pt – Verification success! No problems found.
l10n/ru – Verification success! No problems found.
l10n/sv – Verification success! No problems found.
l10n/ta – Verification success! No problems found.
l10n/th – Verification success! No problems found.
l10n/tr – Verification success! No problems found.
l10n/ur – Verification success! No problems found.
l10n/vi – Verification success! No problems found.
l10n/zh-TW – Verification success! No problems found.
l10n/zh – Verification success! No problems found.

[szemet]

In the file _event_handlers.php_ if I uncomment this code and add the $Filename as a fixed string the logging works again.

$CIDRAM['Events']->addHandler('writeToLog', function () use (&$CIDRAM): bool {
    /** Guard.
    if (
        !$CIDRAM['Config']['general']['logfile'] ||
        !($Filename = $CIDRAM['BuildPath']($CIDRAM['Vault'] . $CIDRAM['Config']['general']['logfile']))
    ) {
        return false;
    }*/
$Filename = "/home/sidedir/public_html/cidramdir/vault/log/log.log";

I caught an error message too while repair all after playing with the code:
Warning: mkdir(): open_basedir restriction in effect. File(/home) is not within the allowed path(s): (/home/sitedir/public_html:/opt/remi/php72/root/usr/share/pear:/usr/lib/php:/usr/local/lib/php:/tmp) in /home/sitedir/public_html/cidram/vault/functions.php on line 1661

It is a shared hosting, so the /home isn't writable by me. So the BuildPath fails and this must be the reason for no logging.

[Maikuolan]

Cheers. Looking into this now. :+1:

[Maikuolan]

Any idea whether /home might be symlinked, or might be a virtual directory, or something like that (instead of a normal, real directory)?

The reason I'm wondering, is that the only call to mkdir within BuildPath, should trigger only if is_dir returns false for the segment of the path in question:

        if (!is_dir($Rebuilt) && !mkdir($Rebuilt)) {
            return '';
        }

So, because of the particular error encountered (Warning: mkdir(): open_basedir ...), I'm wondering whether there might be something special about /home at your server.

Reading through PHP's documentation for is_dir, it seems that it should, in most cases, still always return true, as long as the directory in question exists, even if the directory is symlinked, but reading through some of the comments there suggests that there may sometimes be different behaviour at different systems/environments/etc, so I'm considering that as a possible (albeit unconfirmed) explanation.

[szemet]

Tried it and everything is working fine if the return ''; part removed from the above.

The log file full url is this: _/home/sitedir/public_html/cidramdir/vault/log/log.log_ and from this I manage only the _/public_html_ and bellow as this is a shared hosting.

edit: is_link tells me that /home and /home/sitedir is not symlink, but this may wrong as I don't have permission over them

edit2: if I move the above if sentence below the next "}" works and the check is still runs on the full path once.

edit3: Maybe simply this is a permission iusse is_dir fails on /home and /home/sitedir as I have no permission over them.

[Maikuolan]

edit3: Maybe simply this is a permission iusse is_dir fails on /home and /home/sitedir as I have no permission over them.

Ah, good point. I hadn't considered that before. I guess, if is_dir is also affected by open_basedir, that would cause it to fail, too.

Maybe, for a solution, I'll just need to make a way to toggle BuildPath on/off, for cases like these. (Since you mentioned that logging seems to work again without BuildPath). Main purpose for BuildPath is to ensure that a specified path is available for the operation needing it (e.g., logging), rejecting a path if the path is syntactically incorrect, creating necessary directories if the path is syntactically correct but missing some of the needed directories, etc. As long as all the directories in specified path already exist, and the endpoint where the file is to be created/modified/etc writable, BuildPath won't be needed.

I'll see what I can do for that shortly.

[Maikuolan]

Okay.. This is interesting.

It seems that theres's a bug in PHP, which has already been reported and known since 2015, but which still remains open and unfixed, even in the latest versions: https://bugs.php.net/bug.php?id=69240

I tested this just now, at my local system, and can confirm the continued existence of the bug (tested using the current latest available PHP versions):

C:\Users\Caleb>php -d open_basedir=/Users/Caleb -r "echo is_dir('/Users/Caleb')?'y':'n';
y
C:\Users\Caleb>php -d open_basedir=/Users/Caleb2 -r "echo is_dir('/Users/Caleb2')?'y':'n';
PHP Warning:  is_dir(): open_basedir restriction in effect. File(/Users/Caleb2) is not within the allowed path(s): (/Users/Caleb2) in Command line code on line 1

Warning: is_dir(): open_basedir restriction in effect. File(/Users/Caleb2) is not within the allowed path(s): (/Users/Caleb2) in Command line code on line 1
n
C:\Users\Caleb>

Not sure whether that bug is exactly what's coming into play here in your case, but regardless, because of this bug, I think I'm going to need to just avoid most of the BuildPath process for installations wherever open_basedir is populated (since the main purpose of BuildPath is checking for non-existent directories and creating them whenever necessary, and as long as that bug remains unpatched, non-existent directories will cause that error message to appear, regardless of whether the path is or isn't among the paths permitted by open_basedir), and once implemented, the solution should also resolve the problem at your end.

Removing Support label and adding Bug label. I'll reply again after I've committed something workable. :+1:

[szemet]

What if you move the

        if (!is_dir($Rebuilt) && !mkdir($Rebuilt)) {
            return '';
        }

part, with one '}' bellow. Then it will test the full BuildPath as the comment already says (/** Return an empty string if the final rebuilt path isn't writable. */) in the code. Beceause now it walks trough the recreation of the full path piece by piece and not only the final path.

[Maikuolan]

I've pushed these changes just now:

+   /** We'll skip is_dir/mkdir calls if open_basedir is populated (to avoid PHP bug #69240). */
+   $Restrictions = strlen(ini_get('open_basedir')) > 0;
+
    /** Split path into steps. */
    $Steps = preg_split('~[\\\/]~', $Path, -1, PREG_SPLIT_NO_EMPTY);

@@ -1658,11 +1661,16 @@
        if (preg_match('~^\.+$~', $Step)) {
            continue;
        }
-       if (!is_dir($Rebuilt) && !mkdir($Rebuilt)) {
+       if (!$Restrictions && !is_dir($Rebuilt) && !mkdir($Rebuilt)) {
            return '';
        }
    }

Let me know whether that does the trick. :-)

[szemet]

It works now as it should.