YetiForceCompany / YetiForceCRM

Our team created for you one of the most innovative CRM systems that supports mainly business processes and allows for customization according to your needs. Be ahead of your competition and implement YetiForce!
https://yetiforce.com
Other
1.74k stars 749 forks source link

cron php.ini #12712

Closed ohandy1 closed 4 years ago

ohandy1 commented 4 years ago

yetiforce_settings I've tried figuring this out for over a year now (off and on). In my server config logs my cron (CLI) settings are vastly different from my php.ini. I've tried forcing the use of the local ini file in the cron command, I've tried editing the cron.sh but can't get it to stop using the wrong ini file.

davide-alghi commented 4 years ago

Hi @ohandy1, surely you know that Apache PHP has its php.ini and PHP CLI has its php.ini, usually:

additional notes:

ohandy1 commented 4 years ago

Surely you know I use WHM because server management is a diminishing skill. I don't do it every day so it goes away. I couldn't even remember to post this query correctly... need that jellyfish drug for my brain. Thank you kindly for the file locations.

ohandy1 commented 4 years ago

BTW, those file locations are wrong for centos7 using WHM. guess it's just one of those things...

davide-alghi commented 4 years ago

yes, sorry, you're right. from your log both apache and cli use the same php.ini /opt/cpanel/ea-php72/root/etc/php.ini

so I cannot understand how you have different values for Apache PHP and PHP CLI :( the only idea, but I have never see this, is that in the same php.ini you can distinguish between apache and cli: I think it's better to ask about your problem to your provider support.

you have discrepancy only in system stability section: in performance and security sections they are (seem) identical

mariuszkrzaczkowski commented 4 years ago

76707685-ae7a5800-66c7-11ea-9349-6b769eb7a055~4

davide-alghi commented 4 years ago

hurgh!! yes right Mariusz, many additional config files @ohandy1 you have to modify right ini files into right column to setup PHP CLI

vovpff commented 4 years ago

@davide-alghi I'm not sure what this files need to be modified. I has tuned my webserver while ago and get this configuration report:

ConfReport_200317_2

ohandy1 commented 4 years ago

Well WHM has multi-php and multi ini files so i can use different versions on different domains. It appears the one is overridden by the local ini file while the other isn't. I can modify the default ini file and it looks like that should work, but it would be better if I could direct YF to use the local file instead of the server default.

davide-alghi commented 4 years ago

tomorrow I will take some time to understand: now my mind works halfway :D

vovpff commented 4 years ago

@ohandy1 at first apply public_html. This folder contains .user.ini file what contains overrides of parameters for your php config. This file should be hooked automatically.

davide-alghi commented 4 years ago

@davide-alghi I'm not sure what this files need to be modified. I has tuned my webserver while ago and get this configuration report:

Good morning Vladimir, about your question ...

System header configuration: these are headers that your web-server send to client browser. to change these values you need to install+enable headers module for Apache 2 and install+enable libapache2-mod-security2 module for Apache 2 (moreover it requires adequate configuration). but changing these values to YF-reccomended ones requires https. you are not in https, so you cannot do that. NB: these sent values are exactly the same as YF5.2, nothing different; just now you can see those into YF Server configuration log

Environment information: _Error logs (errorlog), simply set error log path into php.ini _openbasedir: you can set this to your YF root folder, but take into account that whether you are running other web applications on your web-server, you need to include (into open_basedir directive) all web applications root folders too openssl.cafile and openssl.capath: they are alternative folders where Apache looks for ssl certificates, but you are not in https, so you don't need to set them

davide-alghi commented 4 years ago

@ohandy1 at first apply public_html. This folder contains .user.ini file what contains overrides of parameters for your php config. This file should be hooked automatically.

just a quick note: .user.ini file is into YF root folder too

davide-alghi commented 4 years ago

Well WHM has multi-php and multi ini files so i can use different versions on different domains. It appears the one is overridden by the local ini file while the other isn't. I can modify the default ini file and it looks like that should work, but it would be better if I could direct YF to use the local file instead of the server default.

Good morning @ohandy1,

no. to specify a php.ini file(s) for single domain, you need to set PHPINIDir directive into virtual-host configuration.

let's go back to your original problem: your php.ini file is spitted into large number of smaller php.ini. you can see this on Mariusz attachment. each of these small file configure a specific group of values. so you have to identify correct small file for each parameter to change. in my installation I have a single file php.ini with all configuration included: in your installation you have multiple files ... anyway ... I just compared file-paths and filenames for apache and cli, and it seems they are the same for both, but you can do a deeper check on this.

sincerely I cannot give you more information on how change php-cli configuration

ohandy1 commented 4 years ago

Thank you all, I've learned some new things with this. This looks like an issue created by how WHM/Cpanel manages the multi-php and multi-php.ini files. I'll pursue a greater understanding on the cpanel forum, and for the $$ they get from me (new pricing structure) I'll start a ticket.

I'll close the ticket even though I haven't quite sorted out the details. When I get the chance I'll experiment with installing this on a VPS with no competing software.

I'd love to be able to offer this to my web clients, but really need to understand it first, so I'll likely be back.