Executing shell scripts

[southbeach]

I am working on a legacy application and PHP project. Running on SCO UNIX ...

I have worked on other systems under the same environment but this time, I am having a problem executing shell scripts. I use system() to execute the script. The script can be something like:

/usr/local/bin/script_name

If I run the script from the CLI or command prompt, all works well. I checked permissions and ownership and it looks good.

chmod 755 and chown root:group

What do you think I may be missing?


--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[jpadie]

it's a permissions thing. under the web server your script will run with the apache permssions. under CLI it will run with the permissions of the user with which you log in.

so two options: either add the apache process to the relevant group (bad idea) or adapt your script to use sudo.

 

[DonQuichote]

What I am missing is what actually is "a problem".

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[southbeach]

I cannot get the script to run no matter what I do. I have set mod to 755 and 777 ... nothing. I changed system() for exec(sudo -u root [comand]) and nothing.

I cannot even get a listing of the tmp directory. Do I need a module/extension loaded for this to work?

@DonQuichote: The problem is that the whole concept behind the PHP script is to gather some data online, run shell script and come back with data from legacy application. Application is not an ODBC compliant application so I must use its own means to extract data; best way to do this is by producing flat files and manipulating these files with PHP.



--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[jpadie]

well, sudo will need a password. and, of course, you will need the apache process to be in the sudoers group (/etc/sudoers). We are straying way outside php territory through.

If you need to run a script with root privileges you do this

> sudo -u root .somescript.sh
> pasword: mypassword

to if you want to do that in php you create a file somewhere outside of the web root with your password in it. just the password and a new line character

then

$command = 'sudo -u root .somescript.sh < /path/to/my/password/file.txt';
exec ($command);

 

[DonQuichote]

OK. The reason I asked is this: is there any output at all? If there is a non-zero return value, the script or command had a problem itself. There are a lot of things that can go wrong: typos, escaping problems, execution rights and off course "safe mode" settings in PHP.ini.

As I encountered similar problems in the past, I wrote a little class to have the greatest possible monitoring options. You can find it at:

https://opensvn.csie.org/TinyCollection/ShellCommand/trunk/code/shellcommand.php

(it's a subversion repository, so you see the source if you follow that link)

You can use it to check for non-zero return codes and to check for output to the error stream.

If there is no output whatsoever (not even a return code or something on the error stream), a rights problem is the most probable cause. Also check for "safe mode" in the servers config.

If you are on linux (which I assume from your chmod calls), you can check which user is used by letting PHP run the command "whoami" on the shell and capturing the output. This will ensure you that you give permissions to the right user.

Furthermore, there may be an environment problem: the PATH setting could be different from the shell command than from an xterminal. So it may help to give full paths for everything the script has to use.

Hope this is of any help.

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[southbeach]

@DonQuichote,

I tried your link but it fails ... :-(

I have tried samples provided in php.net trying to troubleshoot the problem and no matter what I tried, I simply cannot get a shell script to run.

I am using SCO UNIX 5.0.7 and PHP 4.4.2 and Apache 1.3.36 - save_mode is set to OFF as per php_info().

It just does not matter where the script is, none of them execute. I have done same type of work in a number of other servers (same OS and legacy application) and had never encountered this problem.

I am going to try running a script within web site root directory and see if it executes there.

Thanks!


--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[DonQuichote]

Ah. If you are still using PHP4, my class won't work anyway. I have a gut feeling that it may be PHP that is silencing all kinds of warnings (which is prudent on a server). Can you replicate the problem on a development machine or set all warnings on for a short while?

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[southbeach]

Here is the PHP code

<?PHP

	ini_set('display_errors',1);
	error_reporting(E_ALL|E_STRICT);

	$msg='';
	if($_POST['mawb'] != '') {
		$unique = uniqid(''); $filename = './txtdata/'.$unique;
		$command = './getData "'.$unique.'" "'.$_POST['mawb'].'" "'.$_POST['hawb'].'" > /dev/null';
		exec('sudo -u root '.$command); 
		echo $command;
		system ($command);
		$filerror = $filename.'.err'; $datafile = $filename.'.data';
		if (file_exists($filerror)) {
			$file = fopen($filerror);
			$string = fread($file);
			list($msg,$eol)=explode("~", $string);
		} elseif (file_exists($datafile)) {
			$file = fopen($datafile);
			$string = fread($file);
			list($company,$office,$master,$client,$origin,$dest,$terminal,$etadate,$carrier,$flight,$agent,$house,$partial,$action,$cbsa,$country,$fda,$gross,$qty,$qty2,$partial,$custom01,$custom02,$custom03,$custom04,$custom05,$custom06,$custom07,$custom08,$custom09,$custom10,$custom11,$custom12,$stat01,$stat02,$stat03,$stat04,$stat05,$stat06,$stat07,$stat08,$stat09,$stat10,$stat11,$stat12,$date01,$date02,$date03,$date04,$date05,$date06,$date07,$date08,$date09,$date10,$date11,$date12,$type01,$type02,$type03,$type04,$type05,$type06,$type07,$type08,$type09,$type10,$type11,$type12,$comm01,$comm02,$comm03,$comm04,$comm05,$eol)=explode("~", $string);
		} else { $msg='System Error: Failed to retrieve search results.'; }
	}
?>

The shell script, among other commands, I have

echo $1 > /tmp/joselog
echo $2 >> /tmp/joselog
echo $3 >> /tmp/joselog

I have tried scripts that simply execute commands such as l -l, who am i, echo 'Hello World!' ... and nothing.

Even with the error reporting set nothing is shown ...



--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[jpadie]

it won't work!! you need a password with sudo.

have you looked at my post?

 

[southbeach]

@jpadie,

Sorry, I do not know how what I posted has the exec() command un-remmed. Please notice that I have the system() command a couple of lines below the exec() command.

I did see your post and I am trying to get this to work and keep jumping back and forth between exec() and system().




--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[DonQuichote]

Two things: sudo may be waiting for a password. That all depends on how sudo is configured. Assuming user "apache" is used by PHP, you could try in a terminal:

sudo -u apache ls
sudo -u apache 'sudo -u root getData a b c'

and see if you have to give more passwords with the second line.

Furthermore, I would use absolute paths. If the path is meant to be relative to the executing script, use something like dirname(__FILE___) . '/getData'. Note that the outcome of dirname() does not end in a slash, so you will have to add one yourself.

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[DonQuichote]

One more thing:

If you want to execute it as root, drop sudo and set the GUID bit on the file. This will force the file to be executed as its owner. For instance, this is how ping is executed.

chmod u+s getData

After that, the script will be executed as its owner, regardless on who calls it. So if it is owned by root, it is executed as root.

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[DonQuichote]

Ahhh I'm typing too fast. That should have been the SUID bit (see the chmod man page).

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[lgarner]

Your example has "./getData" as the command. Have you tried with the full path?

 

[southbeach]

I have tried full path, I have tried running the script out of /tmp directory.

Let me create a directory and set it as owned by apache:group and see what happens ...



--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[southbeach]

I cannot figure this one out. Since I am running on SCO UNIX, it appears that sudo is not an option. I have spent way too long on this without making any progress, I am exactly where I was a couple of days back (a bit more frustrated ...).

Does tek-tip have a for hire forum? I was not able to find it. I can put project owner in contact with one whom may solve this for us.

Thanks!


--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[jpadie]

no. tek-tips does not condone offering or seeking services.
i'd suggest you go to rentacoder.com

 

[southbeach]

OK - While comparing the output rendered by php_info() between a server where script works well and the server that does not (both SCO UNIX), I found a section where a list of variables are shown.

There are two columns Name and Value ... Where are these variables set?

I have edited httpd.conf and changed user and usergroup to match that of the owner of the legacy application, still no luck.


--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.

 

[southbeach]

A correction to my last post: I meant Environment - not Variables ...

Sorry!


--
SouthBeach
The good thing about not knowing is the opportunity to learn - Yours truly, 2008.