php shell_exec() freeradius command - php

i have this problem: i want execute a command freeradius from the instruction php exec(), but it doesn't work. the code is simple:
<?php
exec('radzap -x -N 192.168.0.1 localhost secret');
?>
If I run the code in the shell work, but into the script php doeesn't work, other instructions like 'ls' ,'cd' and the other 'classical' commando work.
I utilize Fedora, maybe i don't have the permissions how user 'Apache' to utilize the dictionary Freeradius.
Sorry for my english, any suggestions? Thank
Update:
the error is:
dict_init: Couldn't open dictionary "/etc/raddb/dictionary": Permission denied
Ok, i found the error (maybe), selinux don't permict the execution of this instruction, if i set selinix permessive work, if is enable doesn't work.
It's work finally, i changed the file's permissions for user Httpd and the instruction go.

The problem isn't just that the command is failing, but it's that you don't know how it's failing. exec() doesn't give you a whole lot of information by itself, so you'll need to capture the command output (including standard error):
$output = array();
$retcode = 0;
exec('radzap -x -N 192.168.0.1 localhost secret 2>&1', $output, $retcode);
echo "Return code: $retcode\n";
print_r($output);
This gives you the command's return code and output, allowing you to see why the command is failing. There are too many possible problems to give you a specific answer.
Having said that, the most common reason for commands failing is that the binary can't be found, due to the $PATH environment variable. Try specifying the absolute path to radzap in exec, e.g. /usr/bin/radzap.

Related

PHP exec() with Pygments for PHP

I'm currently using the Pygments for PHP plugin that is located here: http://derek.simkowiak.net/pygments-for-php/.
The line that actually calls Pygments from that code is an exec() passed: pygmentize -f html $extra_opts -l $language $temp_name as the command. This all works fine, and I get back the output and it is formatted by the plugin.
What I would like to happen at the same time is for Pygments to create an image of it, so I pass exec() a similar command: pygmentize -f png $extra_opts -l $language -o $full_image_path/$output_file.png $temp_name This is where I run into a problem. The image never shows up in the expected folder.
However, if I var_dump() that command string before I exec() it and take it and run it straight from the command line, it works fine.
I have tried echoing exec('whoami') which tells me that the PHP user is www-data. I've tried giving permissions to www-data and changing ownership to www-data on the folder where I store the images. I've also tried changing permissions to 777 just to see what would happen, and the answer is nothing.
Is there something I'm missing? I'm running out of ideas to try. Thank you!
Edit: Another thing that I've checked is the output from the exec command, and the return value. It outputs an empty array, and it returns 1 as the return value.
Edit 2: After seeing that that directory should be writeable/readable for the PHP user, is it possible that pygments doesn't have permission to write it as a specific user? I'm not sure this makes sense, as when I run it myself it works fine, and in fact, when PHP runs it with the HTML lexer, it is able to run. I'm not very experienced in Python, so I don't know if this is a potential issue.
I guess you cannot do it like this.
$output_file.png
Try
$file = $output_file.".png"
and substitute in the exec
Ended up being an issue with the font that was installed for use by the www-root user. Apparently the one that is used by default for Pygments was installed only for the user that I was running as when I use the command line.
The way I was able to figure this out, was running
exec("$command 2>&1", $out, $code);.
The extra 2>&1 redirects stderr into the output for me to see the issue.
The $out parameter showed the FontNotFound error that pygments was throwing.
I changed the font that Pygments used via the command line using: full,style=manni,cssclass=pygmentize_kbOKBd,font_name='DejaVu Sans Mono' -l php -o /srv/www/path/to/images/uploads/2513732976ad4b7.02729290.png /tmp/pygmentize_kbOKBd after finding which fonts I had available to me.
To see which fonts I had available to me as the user running the script, I just ran fc-list in an exec() command for Ubuntu, and checked the output of that for the list of available fonts.

Can I rip DVDs from a local web app with HandBrake?

I'm building a PHP web application that will run on my machine, and one of its purposes is to call HandBrakeCLI with an exec() or similar call. If I run the command
HandBrakeCLI -i path_to_dvd_drive -o output_file --preset preset_name
from a shell, it works fine. However, when I put the exact same command in an exec() php function (or similar), it doesn't work, and doesn't return anything, aside from a return status of 0. No errors, nothing else.
Is this just a simple permissions issue that I'm not seeing, due to the lack of errors being spit out? Or am I missing something else?
For debugging, try running the command from the console but as the user PHP runs as. Here are some pointers how to find out which user that is.
Then use sudo to run the command as the Apache user. You will probably get more helpful information from that.
try to exec your script using absolute path (type which HandBrakeCLI in terminal to find it) and append 2>&1 to the end of command, like:
exec('HandBrakeCLI -i path_to_dvd_drive -o output_file --preset preset_name 2>&1')
this way if command outputs anything to stderr you will see it.
is handbrake in the path of whatever shell PHP is invoking when it does the exec()? Does whatever account PHP/webserver is running under have access to the directory where handbrak.exe is, and have permission to execute handbrake.exe? Does the webserver account have permissions to access the dvd drive, etc...
Many things to check, and without better diagnostic information, this is about the best you'll be able to get here.

Why isn't this shell command giving the desired result?

I am using the wkhtmtoimage library on my server, and I have managed to get the output for the following command when I am running in PuTTY:
wkhtmltoimage www.google.com test.jpg
But, when I use the following shell command I don't get the output, and I don't know why.
$filnename = "test.jpg";
$url = "http://www.google.com";
shell_exec("wkhtmltoimage $url $filename");
Even I tried with this variation instead, but still without getting the desired result:
shell_exec("/usr/local/bin/wkhtmltoimage $url $filename");
What am I doing wrong?
Edit:
I downloaded the Linux binary and put it into the folder then I ran it.Whether I need to restart the server the changes affected?
shell_exec command is allowed because we used it for ffmpeg(already installed one)
I cannot give an exact solution but if you can try out what I write I might be of help. I will list more solutions if the one I am providing does not work.
Solution proposal 1:
Use quotes around url and filename
shell_exec("wkhtmltoimage \"$url\" \"$filename\"");
Solution proposal 2:
Try redirecting streams to files and type the contents.
shell_exec("wkhtmltoimage \"$url\" \"$filename\" > output.txt 2> error.txt");
May be user under which PHP (or Apache) runs have no permissions to run this tool. Try printing output of this command or just use passthru() to directly print output of command.
Another solution is to pass output to files as #Cem_Kalyoncu wrote.

Trouble running subversion through PHP's exec

I can run an svn command from the command line but not from within a PHP script. Significantly, I can run the PHP script on my Mac and it returns the expected data just fine but when I upload it to my Linux server it won't work (from within PHP... I can run the svn command from the terminal). I'm pretty sure this is a user or permission issue of some sort.
I can run (from command line):
svn log http://whatever.com/svn/foo
but none of the following work (run separately... not all together like this):
exec('svn log http://whatever.com/svn/foo');
exec('svn log http://whatever.com/svn/foo',$out);
exec('/usr/bin/svn log http://whatever.com/svn/foo');
However this works:
exec('ls');
I assume the problem is that when I run from the command line I am running as root whereas when I run from PHP I am running as the apache user (www-data)? Perhaps? Any suggestions on how to be able to run exec('svn log http://whatever.com/svn/foo');?
Changing permissions to 777 (just trying to get it working!) does not help.
Here are a couple of threads that I think might help:
Thread 1 (read as there is more):
$cmd = '/usr/bin/svn list --config-dir /some/place file:///var/subversion/devfoundry/ 2>&1';
exec($cmd, $output);
$output = implode("\n", $output) . "\n";
echo $output;
Thread 2:
The Subversion error "svn: Can't
recode string" can be caused by the
locale being wrong. Try
<?php
putenv('LANG=en_US.UTF-8');
?>
(or whatever your preferred locale is)
before you call shell_exec()
Thread 3: PHP Interactive Shell
May be you can use a svn client for php. Here is a good one
http://code.google.com/p/phpsvnclient/
When you run Subversion from the command line, you are running it as yourself. That is, you are the user logged in and running the command.
If you are running Php from a webpage, it is the user who is running the Apache httpd daemon (which could be "apache", "www", "runwww", etc. depending upon the platform). The user running the PHP script may not have read/write permissions to the Subversion repository.
You have two ways of solving this:
Provide your program with user credentials via the --username and --password command line parameters.
Setup the user running httpd with Subversion credentials. Once it is done, it'll never have to be done again. This way, your PHP code doesn't contain login credentials.

Problems when trying to exectue exec("unix2dos xxx") in PHP/Apache

In a previous post, I was trying to update the encoding for a download file from php. One of the suggestions was to run the unix2dos command before sending the file to the user. This works great when I run the command on the linux box, but when I try and run the command from php I get nothing. Here is what I tried:
$cmd = "unix2dos -n $fullPath $downloadFile";
echo exec($cmd, $out, $retVal);
This displays nothing to the screen, $retVal is 0, and $out is an empty string.
echo system($cmd, $retVal);
This displays nothing to the screen, $retVal is 0.
echo shell_exec($cmd);
This displays nothing to the screen.
I have also tried escaping the command and it parameters like:
$cmd = escapeshellcmd($cmd);
and
$cmd = "unix2dos ". escapeshellarg("-n \"$fullPath\" \"$downloadFile\"");
Please let me know if you see something that I am doing wrong.
Thanks!
Edit: Here is some info that may be helpful.
unix2dos version: 2.2 (1995.03.31)
php version 5.2.9
Running in apache 2 on in Redhat Enterprise Linux 4
Have you considered a pure PHP solution?
<?php
$unixfile = file_get_content('/location/of/file/');
$dosfile= str_replace("\n", "\r\n", $unixfile );
file_put_contents('/location/of/file/', $dosfile);
?>
Something like that should do it, although untested :)
Shadi
See which user the PHP exec command is running as:
<?php system('whoami'); ?>
If this command fails then you likely do not have permission to use exec() or system(), so check your INI files. But be sure to check the correct ones! On Debian systems there are separate Apache and CLI INI files stored at /etc/php5/apache/php.ini and /etc/php5/cli/php.ini respectively. Sorry I do not know the locations for RedHat.
If the whoami command succeeds, make sure that the unix2dos command can be run by the user that is shown, and that the same user is allowed to make changes to the files in question by using chmod or chown.
Are you using the full path to unix2dos? Perhaps the executable is in your path for your shell but not in the path that PHP is using.
My implementation of unix2dos produces no output. If the return value is 0 then the command succeeded and your file has been updated.
The only other thing I see is the -n option which my version doesn't seem to have. You should probably check your man page to see what options it supports
unix2dos does not display the file it converts. Therefor you must display it yourself. A very basic way to do it could be :
$cmd = "unix2dos -n $fullPath $downloadFile";
echo exec($cmd, $out, $retVal);
include "$fullPath."/".$downloadFile;
Using include is pretty dirty but quick and easy. A cleaner way would be to use fopen and read the file then display it.
You'd better create a function that enclose all the operation : conversion + display so you'll have everything at hands.
But, If I were you, I'd prefer to not use exec at all and use FileIterator with a trim on every line so you will not have to care about the carriage return nor deal with a hazardous shell binding.
Not sure about your exact problem, but debugging suggestion:
Try first setting $cmd to ls. See if that works. Then try using /bin/ls (use the full path.)
If those don't work, then there might be a problem with your PHP configuration - there might be a safemode parameter or something which disallows the use of exec(), shell_exec(), or system() functions.
I got the source code from here.
http://www.sfr-fresh.com/linux/misc/unix2dos-2.2.src.tar.gz
I compiled it and then ran the tool. This was my output:
rascher#danish:~/unix2dos$ ./a.out -n 1.txt 2.txt
unix2dos: converting file 1.txt to file 2.txt in DOS format ...
I think the problem is this: the program writes all of its output to stderr, rather than stdout. If you look at the source code, you can see "fprintf(stderr, ...)"
As far as I know, PHP will only read the part of your program's output that is sent to STDOUT. So to overcome this, it seems like you have to redirect the output of your program (unix2dos uses stderr) to stdout. To do this, try something like:
$cmd = "unix2dos -n $fullPath $downloadFile 2>&1"
The "2>" means "redirect stderr" and "&1" means "to stdout".
In either case, I would imagine that the file was converting properly, but since you weren't getting any of the expected output, you thought it was failing. Before making the change, check on the output file to see if it is in DOS or UNIX format.

Categories