Command exec and php shell_exec have different results - php

I am trying to create a print server using PHP - Lumen using Cups on a CentOS 7.
The result of lpstat -p -d in my command shell is :
printer ZTC_GK420t is idle. enabled since Thu Apr 25 17:50:41 2019
no system default destination
The result of a php script :
$output = shell_exec("lpstat -p -d");
Is :
Array
(
[0] => no system default destination
[1] =>
)
What could be the cause of this? I have the same results with PHP exec() & system().
The code is working as expected on a MacOs

The only thing that may make results different here is the difference of privileges available to the user in your shell and the user PHP running under .

Related

PHP exec blank page

First of all, I tried this all on a Windows 10 machine, and I expect a blank page if I don't use echo.
But the code doesn't work.
<?php
exec ('cmd.exe server.bat 2>&1', $output);
print_r($output);
?>
output:
Array ( [0] => Microsoft Windows [Version 10.0.17134.228] [1] => (c) 2018 Microsoft Corporation. All rights reserved. [2] => [3] => C:\wamp64\www\server> )
<?php
exec ("cmd.exe server.bat 2>&1", $output);
print_r($output);
?>
A subdirectory or file .exe already exists. Error occurred while processing: .exe. A subdirectory or file server.bat already exists. Error occurred while processing: server.bat.
This bat file is in the same directory as the PHP script.
#echo on
cd /
cd wamp64
cd www
cd minecraft-server-stuff
start java -Xms1024M -Xmx16G -jar server.jar
PHP itself is enabled in httpd-conf.
I tried Apache as admin ( my Microsoft account name), this does change the executer to me.
Safe_mode is not available as an option so I can't disable it( I assume that not available means not active), maybe because it was removed in PHP 5.4.
Currently using PHP 7.something
I am using wampserver, which is using the .ini of php5.3.44
I tried setting the user in the httpd-conf as me, I have little coding experience so I don't know how to verify if that works.
I tried setting Apache as my account, this appears to set Apache as my account.
I currently don't have access to the logs( not that it logs anything but actual code things, like syntax error and such)
I also don't have access to any other code, due to the fact that I am on work.
A .bat file is not an executable in itself. I suppose that the exec instruction is not able to run this as a system program. You probably need to invoke the actual command interpreter (cmd.exe) to which you pass, as an argument, the name of your .bat file.

Running backgrounded script from php exec / shell_exec call is now failing and re-spawning where before it used to work

There is a commonly discussed method of starting a background process in PHP using the exec or shell_exec functionality.
I have had success with this in the past with batch email sending, and sending data to APIs in the background.
In a PHP page that you would call by ajax, you do something like this:
echo 'process running';
shell_exec('/usr/bin/php -q path_to_background_script.php > /dev/null &' );
exit;
The background process normally runs as if called by the owner of the php user like a terminal process.
Recently however, under a FASTCGI system (ea-php56) I have found this method has stopped working.
Instead of one process beginning from one web-request to the calling page, I am getting the background script continually terminating and being re-spawned with a new process id. Interestingly, the only way to stop this continual re-spawning is to disable the line in the calling script that starts the process. The re-spawning stops immediately when you save the calling file without the call to the background script.
This tells me that it is actually the calling script (requested by the browser) which is actually being re-spawned.
This is what the re-spawning looks like from the root terminal. Notice the PID changes everytime I look:
[root#*** public_html]# ps -ef | grep php
*user* 725 1 7 23:53 ? 00:00:00 /opt/cpanel/ea-php56/root/usr/bin/php-cgi /home/*user*/public_html/background-script_exec.php
root 727 32411 0 23:53 pts/1 00:00:00 grep php
[root#dev public_html]# ps -ef | grep php
*user* 757 1 5 23:53 ? 00:00:00 /opt/cpanel/ea-php56/root/usr/bin/php-cgi /home/*user*/public_html/background-script_exec.php
root 759 32411 0 23:53 pts/1 00:00:00 grep php
[root#dev public_html]# ps -ef | grep php
*user* 781 1 12 23:54 ? 00:00:00 /opt/cpanel/ea-php56/root/usr/bin/php-cgi /home/*user*/public_html/background-script_exec.php
I have tried disabling "PHP-FPM service for cPanel Daemons". I have tried 'ignore_user_abort()'. fastcgi_finish_request() function is not available so could not try that. I have tried creating a shell script instead to call the background PHP script, which I call from the calling script - but this also does exactly the same thing.
Apart from disabling the ability to trigger background scripts from a PHP web-page, this new PHP FastCGI behaviour is creating an erratic re-spawning process that does not stop without intervention mentioned above. It has made shell_exec / exec functions unstable!
Problem seems similar to that reported here:
php exec/shell_exec/system/popen/proc_open runs calling script itself infinite number of times on linux
but, suggestion reported here does not help in this case.
This seems to solve the problem. Using the 'php5-cli' instead of 'php'
shell_exec('/usr/bin/php5-cli path_to_background_script.php > /dev/null &' );
I had early tried 'php-cli' and found it did not exist - I did not think to check to see that it was named differently!
If having similar problems, have a look for the php binaries:
>>ls /usr/bin/php*
>>/usr/bin/php /usr/bin/php5 /usr/bin/php5-cli /usr/bin/php-config /usr/bin/phpize
use the one which is for command line, and it should then run properly.
-note that this issue was specifically on a linux cpanel easy-apache fastcgi-php system running on Centos.

PHP JSON functions not available while being called as CLI script?

Just noticed something, but I'm not sure why this is true, or why it is different than a standard script, maybe someone can help me solve this riddle. When running a PHP script that contains a json_* function from the command line as an executable I will get a Fatal error: Call to undefined function json_encode() in /var/www/jsontest.php on line 6 with the script below
#!/usr/bin/php -n
<?php
$arr = array('foo', 'bar', 'baz');
print_r($json = json_encode($arr));
print_r(json_decode($bar));
This also happens with json_decode() when trying to decode standard clean json input (validated via jsonlint)
The above script was being run as follows, in a Linux/DEB terminal...
$ chmod +x jsontest.php
$ ./jsontest.php
By running this through my local webserver though, I receive my expect output
#!/usr/bin/php -n ["foo","bar","baz"]Array ( [0] => foo [1] => bar [2] => baz )
What is going on? Why is JSON not available when interpreted as an executable?
PHP version is PHP 5.5.3-1ubuntu2 (cli) (built: Oct 9 2013 14:49:24) and PHPInfo for anyone who might want it is published on my Ubuntu One Account
I'm guessing that the issue here is your php.ini file - PHP uses a different ini file when running as CLI. Have a look at Explosion Pill's answer on this question:
When running php from the command line, you can use the -c or
--php-ini argument to point to the php.ini file to use. This will allow you to use one php.ini file for both. You can also alias php to
php -c/path/to/php.ini if you are running the script yourself.

Bash script containing clogin not working when executed via php

I created a simple PHP site we would like to use to disable/enable ports on a cisco switch.
I am passing over two arguments (port and action) to a bash script via the php function exec(). For debugging I set those arguments at the end inside the bash script.
The important part of the php function I am calling looks like this:
function PortAction($port, $action){
echo "<hr /> Port:".$port."<br />Action:".$action;
chdir('/usr/local/icinga-1.7.0/videowand/');
echo exec('sh /usr/local/icinga-1.7.0/videowand/action2.sh 2>&1',$output, $return);
echo "Return / Output: ".$return;
print_r($output);
}
The bash script "action2.sh":
#!/bin/bash
/usr/libexec/rancid/clogin -c "conf t; int Fa0/1; shutdown" 192.168.6.6
If i execute the bash script manually (or even the directly the clogin command) as apache user, it all works as expected, the port gets disabled.
But as soon as I call it over the PHP function, I get the output:
Array ( [0] => no such variable [1] => (read trace on "env(HOME)") [2] => invoked from within [3] => "set password_file $env(HOME)/.cloginrc" [4] => (file "/usr/libexec/rancid/clogin" line 66)
And nothing gets done.
Which indicates some problem with the password entry (as far as I can see).
Permissions on this file(s) are correct, I guess they have to otherwise it wouldn't work directly inside the shell.
Even tried to change the .cloginrc path using the -f switch, no success.
PHP Safe-mode: Off
Display errors: On
The script takes a while because a telnet connection needs to be opened. This is why I put this into a separate bash script.
Provide the full path to the sh binary, like this:
echo exec('/bin/sh /usr/local/icinga-1.7.0/videowand/action2.sh 2>&1',$output, $return);
I'm assuming /bin/sh above, as that is commonly the standard path for sh, but make sure with which sh command.
/bin/sh is a soft link to your shell, which usually is /bin/bash, I'm not sure exec() can work with soft links of binaries, so if above doesn't works then just use /bin/bash instead of /bin/sh

ls output changing when used through exec()

I'm using the ls command via PHP and exec() and I get a different output than when I run the same command via the shell. When running ls through PHP the year and month of the date get changed into the month name:
Running the command through the shell:
$ ls -lh /path/to/file
-rw-r--r-- 1 sysadmin sysadmin 36M 2011-05-18 13:25 file
Running the command via PHP:
<?php
exec("ls -lh /path/to/file", $output);
print_r($output);
/*
Array
(
[0] => -rw-r--r-- 1 sysadmin sysadmin 36M May 18 13:25 file
)
*/
Please note that:
-the issue doesn't occur when I run the PHP script via the cli (it only occurs when run through apache)
-I checked the source code of the page to make sure that what I was seeing was what I was getting (and I do get the month name instead of the proper date)
-I also run the ls command through the shell as the www-data user to see if ls was giving different output depending on the user (the output is the always the same from the shell, that is I get the date in yyyy-mm-dd instead of the month name)
Update with answer
alias was giving me this:
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -alF'
alias ls='ls --color=auto'
From those aliases I was unable to find a switch that was directly responsible for the time display:
-C list entries by columns
-F append indicator (one of */=>#|) to entries
-A do not list implied . and ..
-a do not ignore entries starting with .
-l use a long listing format
However using --time-style=long-iso in PHP did fix the issue.
ls has a couple command line options for date display format. check that your command line version isn't aliased to include something like ls --time-style=locale. The PHP exec'd version will most likely not have this aliasing present and is using default ls settings.
ls output depends from current locale settings. When you run it from console on behalf yourself it uses your locale settings, but user www-data has own locale settings (which probably differ from your). So, I suggest to you specify locale settings explicitly:
exec("LC_TIME=POSIX ls -lh /", $output);
where instead of POSIX you may substitute locale which you want to use.

Resources