O PHP cgi tem seu próprio conjunto de arquivos .ini que diferem do PHP cli?

2

O servidor é:

CentOS Linux release 7.4.1708 (Core) , 3.10.0-693.5.2.el7.x86_64
PHP 5.4.16 (cli) (built: Nov 15 2017 16:33:54)

Não consegui fazer com que o PHP SOAP funcionasse sem um erro das páginas web, embora o teste que fiz funcionasse bem na linha de comando do Linux para PHP cli. Depois de muita pesquisa, encontrei uma sugestão para adicionar o seguinte ao arquivo /etc/php.ini:

extension=soap.so

Isso faz com que as páginas da Web que executam as solicitações SOAP funcionem bem, no entanto, a CLI do PHP está produzindo esse erro:

PHP Warning:  Module 'soap' already loaded in Unknown on line 0

Eu recebo a mensagem acima mesmo fazendo um 'php -v' na linha de comando.

Se o módulo de sabão já estiver carregado, por que o sabão não funciona em páginas da web para cgi? Se já carregou, onde já está carregado e como corrijo isto?

# yum list | grep -i soap
php-soap.x86_64                         5.4.16-43.el7_4                @updates 
CGSI-gSOAP.x86_64                       1.3.10-7.el7                   epel     
CGSI-gSOAP-devel.x86_64                 1.3.10-7.el7                   epel     
SOAPpy.noarch                           0.11.6-17.el7                  base     
fence-agents-vmware-soap.x86_64         4.0.11-66.el7_4.3              updates  
glite-lbjp-common-gsoap-plugin.x86_64   3.2.12-7.el7                   epel     
glite-lbjp-common-gsoap-plugin-devel.x86_64
gsoap.x86_64                            2.8.16-9.el7                   epel     
gsoap-devel.x86_64                      2.8.16-9.el7                   epel     
gsoap-doc.noarch                        2.8.16-9.el7                   epel     
perl-POE-Component-Server-SOAP.noarch   1.14-12.el7                    epel     
perl-SOAP-Lite.noarch                   1.10-1.el7                     epel     
perl-SOAP-WSDL.noarch                   3.003-6.el7                    epel     
perl-SOAP-WSDL-Apache.noarch            3.003-6.el7                    epel     
perl-SOAP-WSDL-examples.noarch          3.003-6.el7                    epel     
php-ZendFramework-Soap.noarch           1.12.20-1.el7                  epel     
php-ZendFramework2-Soap.noarch          2.4.11-1.el7                   epel     
php-pear-SOAP.noarch                    0.13.0-5.el7                   epel     
qtsoap.x86_64                           2.7-9.el7                      epel     
qtsoap-devel.x86_64                     2.7-9.el7                      epel     

Isso existia como parte do 'yum install php-soap':

# cat /etc/php.d/soap.ini
; Enable soap extension module
extension=soap.so

Parece que isso deve ser deixado em paz. Se eu remover a extensão = soap.so do /etc/php.ini, a mensagem de erro de aviso na linha de comando desaparece, mas ela quebra as páginas da Web relacionadas a sabonete php.

Além disso, eu não entendo porque o SOAP para as páginas web do php não é simplesmente instalado e configurado com o resto das instalações do yum para php e soap.

São seus arquivos .ini ou outros arquivos de configuração que precisavam ser alterados para adicionar extension = soap.so? Se sim, onde estão esses arquivos?

Eu executei o programa phpinfo através do navegador da web e na linha de comando e obtive os mesmos resultados para o caminho:

Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d

A exceção é que a partir do navegador da web para "API do servidor" é: Apache 2.0 Handler.

Quando executo isso:

php -i | grep -i soap

Esta é a saída:

PHP Warning:  Module 'soap' already loaded in Unknown on line 0
/etc/php.d/soap.ini,
PHP Warning:  Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in Unknown on line 0
soap
Soap Client => enabled
Soap Server => enabled
soap.wsdl_cache => 1 => 1
soap.wsdl_cache_dir => /tmp => /tmp
soap.wsdl_cache_enabled => 1 => 1
soap.wsdl_cache_limit => 5 => 5
soap.wsdl_cache_ttl => 86400 => 86400

Para comparar, criei uma instância no virtualBox para o CentOS 7 e instalei manualmente o PHP 7 em vez do PHP 5 que vem com o CentOS 7.

PHP 7.0.25 (cli) (built: Oct 27 2017 13:55:11) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

Isso só tem um arquivo php.ini localizado em /etc/php.ini e com soap.so adicionado a ele, ele funciona bem sem erros na linha de comando e phpinfo () executado a partir do servidor também diz que está usando o php.ini em / etc. Ele também mencionou que está usando o /etc/php.d, mas então o PHP 5. Mas o diretório parece diferente mesmo que contenha o mesmo conteúdo do arquivo soap.ini, mas os nomes dos arquivos são diferentes. Na instalação do PHP 7, eles são denominados 20-soap.ini, enquanto na instalação do PHP 5 é chamado soap.ini.

No PHP 5, se eu adicionar soap.so ao arquivo /etc/php.ini, o mesmo que o CGI aparentemente está usando isso faz o SOAP funcionar para o CGI, mas gera um erro na linha de comando sobre o soap já sendo carregado.

Isso pode ser útil, eu editei o php.ini para adicionar o soap.ini e fiz isso:

service httpd restart

Isso faz com que o CGI funcione, e nenhum erro da linha de comando para o PHP, ou seja, até eu reiniciar o servidor e, em seguida, o PHP Aviso sobre o soap já sendo carregado retorna.

Onde mais e como o PHP cli já poderia ter carregado o soap.so que ele não precisa ser adicionado ao arquivo php.ini? Isso poderia significar que o PHP foi compilado com soap.so embutido?

    
por Edward_178118 01.12.2017 / 05:00

4 respostas

1

O caminho do php.ini pode ser diferente para cli e cgi. Teste <?php phpinfo(); ?> com cli e cgi para ver qual caminho eles usam.

2ª volta

Parece-me que o seu executável php cli está ligado ao soap.so é por isso que ele reclama quando você instrui no php.ini para carregá-lo novamente. Por outro lado, o seu servidor web pode usar php através de uma biblioteca compartilhada que não está vinculada ao soap.so, então você precisa da linha "extension = soap.so" no php.ini para carregar soap.so por dlopen (). A solução poderia estar usando um php.ini diferente para a biblioteca php do servidor web e para o executável do php cli como é usual nas distribuições baseadas no Debian. Tente descobrir como o seu servidor web usa o módulo php. Por exemplo. no Ubuntu 16.04 com o apache pode-se encontrar /usr/lib/apache2/modules/libphp7.0.so . Em seguida, compare as bibliotecas vinculadas:

ldd $(which php)
ldd /usr/lib/apache2/modules/libphp7.0.so

(Substitua o caminho na segunda linha pelo caminho do seu módulo php).

Você pode usar a opção -c na linha de comando do php para especificar um arquivo ini diferente.

php -c /etc/php.cli.ini myprogram.php
    
por 05.12.2017 / 21:19
1

A resposta rápida é SIM. Sempre que estou solucionando php, a primeira coisa que faço é um phpinfo () (ou php -i) para verificar qual deles está usando primeiro.

    
por 11.12.2017 / 02:40
1

Sim, é normal. No Debian por exemplo:

root@xxxxx:~# ls /etc/php5/
apache2  cgi  cli  conf.d  fpm  mods-available

Por exemplo, neste caso, há um arquivo php.ini padrão do apache2, outro para o CGI, outro para o FPM e outro para o CLI. Se eu fosse para cada um desses diretórios, eu encontraria um php.ini para cada um.

    
por 11.12.2017 / 18:45
0

O PHP pode ler os arquivos de configuração de forma diferente para o SAPI (API do servidor) e CLI.

Se esta variável de ambiente estiver configurada no seu perfil bash ou no sistema, o PHP irá varrer diretórios procurando por arquivos de configuração.

PHP_INI_SCAN_DIR =: / etc / php.d

Isso soa como o que está acontecendo no seu caso. Essa variável de ambiente pode ser definida para você, mas não para o usuário do apache.

Quando você executa o CLI, ele está lendo todos os arquivos de configuração do php.ini e emitindo esse aviso.

Veja link para mais informações sobre como o PHP está configurado.

    
por 05.12.2017 / 21:06