[ZendTo] Re: ZendTo ANNOUNCE: Release 4.11

[Achim J. Latz]

Hello Jules:

On 08/01/2013 13:07, Jules wrote:
> On 08/01/2013 11:30, Achim J. Latz wrote:
>>     1) You change/override several sensitive and global parameters in
>> /etc/php5/apache2/php.ini, such as error_reporting, display_errors,
>> and apc.slam_defense (which in any case should be 0, not "Off" [1]).
 >
> So 0 is on and 1 if off? That sounds unlikely...

 From [1]: "Setting apc.slam_defense to 75 would mean that there is a 
75% chance that the process will not cache an uncached file. So, the 
higher the setting the greater the defense against cache slams. Setting 
this to 0 disables this feature."

At the moment, the installation sets slamd_defense to "Off" which I 
believe is not a correct value for that parameter.

>> I wonder if this is prudent, especially for error_reporting and
>> display_errors, whose "production value" is hopefully different from
>> the values that you want to use. Doesn't it make more sense to fix
>> errors/clean up code rather than adjust error_reporting?
 >
> They're just harmless notices. I never saw much point in fixing them as
> they're just things that PHP should be able to handle quietly anyway.

I understand that the notices are only minor issues.

I am talking about the installation routine setting the system-wide 
error_reporting and display_errors to a value that is only required for 
"cosmetics" in ZendTo, but might cause problems with other PHP 
applications on the same machine. "display_errors" should certainly be 
Off for all production servers.

Should the installation routine touch those (existing!) values for PHP 
at all, that is the basic question.

>>     2) Even WITH the changes above, I still get the following errors:
>>
>> /usr/bin/php /opt/zendto/sbin/rrdInit.php
>> /opt/zendto/config/preferences.php
>> PHP Notice:  Undefined index: ZENDTOPREFS in
>> /opt/zendto/sbin/rrdInit.php on line 6
>> PHP Notice:  Undefined index: SERVER_PORT in
>> /opt/zendto/lib/NSSDropbox.php on line 41
>> PHP Notice:  Undefined index: HTTPS in /opt/zendto/lib/NSSDropbox.php
>> on line 42
>> PHP Notice:  Undefined index: HTTPS in /opt/zendto/lib/NSSDropbox.php
>> on line 48
>> PHP Notice:  Undefined index: SERVER_NAME in
>> /opt/zendto/lib/NSSDropbox.php on line 48
>> PHP Notice:  Undefined index: REQUEST_URI in
>> /opt/zendto/lib/NSSDropbox.php on line 48
>> PHP Notice:  Undefined index: authIMAPAdmins in
>> /opt/zendto/lib/NSSIMAPAuthenticator.php on line 36
 >
> You need to set error_reporting in /etc/php5/cli/php.ini as well.

And probably only in cli/php.ini, correct? Since we only use those files 
from cron and not from the web interface?

That would also solve the issue with overwriting (customer-facing) 
php.ini for the web applications.

>> 1,2
>> /usr/bin/rrdtool update /var/zendto/rrd/zendto.rrd 1357340400:2:2:9522.4
>>
>> ERROR: /var/zendto/rrd/zendto.rrd: illegal attempt to update using
>> time 1357340400 when last update time is 1357599600 (minimum one
>> second step)
>> 3
>> /usr/bin/rrdtool update /var/zendto/rrd/zendto.rrd 1357599600:1:3:1128.4
>>
>> ERROR: /var/zendto/rrd/zendto.rrd: illegal attempt to update using
>> time 1357599600 when last update time is 1357599600 (minimum one
>> second step)
> That's because of the way that rrdtool works. Whenever ZendTo runs
> rrdtool to do the update, it attempts to rebuild all the stats data that
> it possibly can, in case the RRD database got damaged or deleted for any
> reason. It still has the last month's worth (or whatever you have set
> the drop-off retention time to) of data, so it tries to write all of
> that to RRD. RRD complains about any data which it's already got and
> you're trying to overwrite. So the "ERROR"s from RRD are totally and
> utterly harmless, there's just no way to suppress them without
> redirecting all stderr to /dev/null, which I didn't want to do as it
> does say useful stuff under some circumstances.
>
> Just ignore all those errors. It's normally run from a cron job and that
> output is ditched.

So how do you (manually) detect the "useful stuff" between a flood of 
errors that can be safely ignored? Wouldn't it be (conceptually) easier 
to only get notices when something is wrong, and not having to hunt for 
the real errors in a sea of (wrong, cosmetic, false-positive) errors?

Best regards, Achim

[1] <http://php.net/manual/en/apc.configuration.php#ini.apc.slam-defense>