I've compiled the php 7.4 for centos 7 server. I also have an apache installed 2.4.
The problem is that I have no clue what to do next to make it work. Previously I had 2 sites working with the official package, so the configuration should be fine - the only thing which is changed is the php - completely. Why do I need this compiled php and why I dont like the package? It's because I need ZTS support for the php, which isn't in the precompiled version, and it's necessary for parallel support(multithreading)
On Windows this whole compiling the php and make it working was a joke comparing to this(it was like 1 day with 0 knowledge). I just configured the compiler, compiled, replaced the php folder in the webserver and it was working perfectly and every single tests in the sites were passing as well.
On the other hand in centos, I compiled the php, and some extensions + extra packages to make it work. When I check the modules with
php -m, all of them looks good. The only issue is that the webserver is not loading the sites anymore. Also this is the 4th day I'm suffering with it - there is always a new type of problem.
After I compiled the php I replaced the binary file in the PHP CLI binary. Actually I have no idea if it's a correct thing to do or not, because I can't find any information about this part, because most of the descriptions end where you run the make install command, or do some little bit of extra.
So what I need is some guidance from someone who can explain to me what needs to be done and why should that be done.
There is also php-fpm compiled in the binary, but I dont know if it has an effect on it.
I also have no idea how to debug this situation. I can reach the server, and I can see the default apache testing page, so as expected it didn't changed a bit, and working.
So what I would like to know is some kind of clue about how to figure this out, or some explanation about what files should be placed where and why?
Update after the suggestions:
I went through on the whole process again - created a new volume from the snapshot I made before I started to work on this, and restarted from zero. The today's progress is that after that even the modules weren't loading - zend_opcache and the mongodb. Now after running the
sudo make install cmd, it's clearly says where to put the modules:
/usr/local/php7/lib/php/extensions/no-debug-zts-20190902/ and a description I found also says where to modify what ini file, to make it work:
sudo vim /usr/local/php7/etc/conf.d/modules.ini
But this doesn't do anything anymore, like before. There is also a php.ini file which is suggested to be copied:
sudo cp -v ./php.ini-production /usr/local/php7/lib/php.ini
But modifying that php.ini file to dinamically load the extensions also does nothing, so I guess the php which should use that ini file can't see the file at all. So I checked
whereis php and it says:
php: /usr/share/php /usr/local/php7/bin/php
The second one is what I put into the
$PATH variable, but I think the load order is to load the first one. This was created by the first make install, and this php file is not changing when I run it again. Maybe it has nothing to do with this at all.
Then I had one more type of issue with the httpd, when I ran the
httpd -V cmd:
AH00526: Syntax error on line 216 of /etc/httpd/conf.d/ssl.conf: SuexecUserGroup configured, but suEXEC is disabled: Invalid owner or file mode for /usr/sbin/suexec
which had 510 permission with root:apache user:group pair. Changing it to 0750 solved this issue. I also dont know if it's realated - I guess this time that it must be, because a description I found about the suexec said that it's running the php-cgi. It didn't helped on the overall situation tho.
Then I checked the httpd modules, I did have this module in the
mod_proxy_fcgi.so only, which ofc doesn't mean that it's running the php with this, but I can assume without checking the file - I should confirm it from the config file tho.
There is a file in the conf.d folder:
php.conf.rpmsave, where it says:
# Proxy declaration <Proxy "unix:/var/run/php-fpm/default.sock|fcgi://php-fpm"> # we must declare a parameter in here (doesn't matter which) or it'll not register the proxy ahead of time ProxySet disablereuse=off </Proxy> # Redirect to the proxy <FilesMatch \.php$> SetHandler proxy:fcgi://php-fpm </FilesMatch>
I'm not sure if this matters here, because it might be only a saved config file for the previous package manager php version. Also if I say:
sudo find / -name php.conf or
sudo find / -name *hp.con*, then I get back only this one file, so it seems like the compiled version didn't generate a config file for the apache - maybe it doesn't have to at all, but maybe this is the problem here. Renaming it with mv to php.conf, changes actually the default response from the port 80 from the fancy Testing 123.. to 503 Service Unavailable. This is might be because last time when I compiled the php I excluded the php-fpm, so now I'm going to recompile it once again. Restarting the httpd and php-fpm services after it was done - didn't help on the situation.
From what I see, it's possible to have multiple versions of php script files on the system - which is kinda logical - and the cgi - fcgi, fpm and cli versions are also all different scripts.
Threading is only possible from the CLI version, so maybe if I would use the package version for the sites and then for the threading I would call the compiled CLI php version, then it might would do what I really want it for - as a plan B.
Also php command is not recognised after I installed the compiled versions with the
make install cmd each time. Maybe this is something the installer should take care of - maybe not, after all I put the compiled binary folder into the $PATH variable and also added it to a .sh script in the profile.d folder