Apache/PHP: Executing 'at' scheduled jobs?

bomix · 03-02-2005, 02:50 PM

I have a PHP script on a webpage by which I can (remotely) add scheduled jobs with the at command. Like this:

Code:

  $cmd = 'echo "MyCommand" | at hh:mm mmddyy';
  system($cmd, $returnvalue);

There is no problem adding the jobs. Executing them on the other hand is not working...

I think the problem is that because the job is added by the 'apache' user, it will execute as the 'apache' user. Since the apache user is a nologin-user, the atd daemon will not execute the job.

Any ideas on how to do this? Securely?
I'd rather not have to write any passwords in clear text in my PHP-script or something like that.

My system: Apache 2.0.52 / PHP 5.0.3 on Fedora Core 3.

berrance · 03-02-2005, 03:06 PM

i dont know how to do this but i would like to do something similar. i am in the middle of a compleat overhaul of my network and am going to my website next.

what i would like to do is have a php script that can exicute the uptime command and then display the output of the command on my webpage so people can see how long my server has been up

berrance

bomix · 03-02-2005, 03:33 PM

You should be able to show your uptime with PHP like this:

Code:

  echo "<SomeSuitableTag>";
  passthru("uptime", $returnvalue);
  echo "</SomeSuitableTag>";

These 'un-scheduled' commands are working fine. At least on my system :-)

Anyway, let's keep the focus on how to allow execution of scheduled tasks created by apache/php.

acid_kewpie · 03-02-2005, 03:42 PM

i never had any problem along those lines when i wrote stuff that does exactly that... http://untrepid.com/acidbox this uses an at task to record tv programs, and i didn't touch /etc/passwd or anything. I don't doubt for a second that selinux would throw a fit, but i didn't need to modify any code to get it running. i could make the php source accessible... but there's really nothign to see.... it just worked off the bat. AFAIK, the resulting @ processes spawn in the same way that the httpd processes themselves would do, so there's no reason it can't do that. my passwd entry is: "apache:x:48:48:Apache:/var/www:/bin/false" so it's still totally not allowign a login.

bomix · 03-02-2005, 04:10 PM

Quote:

Originally posted by acid_kewpie
...uses an at task to record tv programs...

That's exactly the same thing I'm doing

Everything else besides this remote-scheduling is working great. This is the last problem I have to overcome before I break out the champagne

Quote:

Originally posted by acid_kewpie
my passwd entry is: "apache:x:48:48:Apache:/var/www:/bin/false"

I have /sbin/nologin instead of your /bin/false. Could that explain the difference? Can anyone confirm that?

I did install this SELinux thingy. I'm quite new here in Linux-land, so I wasn't totally sure what SELinux was, so I just decided to install it to try it out...
Now that it's there, I'd like to find a solution without uninstalling anything. If at all posible.

bomix · 03-02-2005, 04:38 PM

Quote:

Originally posted by acid_kewpie
AFAIK, the resulting @ processes spawn in the same way that the httpd processes themselves would do, so there's no reason it can't do that.

That's my understanding too. If apache creates the task, it will execute as apache. It seems that apache is just not allowed to execute stuff for some reason.

Oh..., I forgot to mention that I added apache to my /etc/at.allow file (and restarted atd), so there must be something else blocking execution.
And syslog doesn't say anything about any blocking... Annoying...

I even tried to chown MyUser:MyUser one of the spool-file that at created. When that executed, MyUser received an email saying:

This account is currently not available.

Hmm... What to do??

acid_kewpie · 03-02-2005, 04:44 PM

well IF selinux is actually enabled as well as installed, that would surely cause it totally choke. basically selinux (security enhanced linux) will only let certain users, most notably apache, access certain locations and resources based on access rights that are theoretcally impossible to break.... and why on earth would apache be running a scheduled task in a nicely managed system?

as for that chown... not a clue.

bomix · 03-02-2005, 05:22 PM

OK, thanks...

I'll look into what SELinux is tomorrow. If I'm running some Security Enhancing stuff it's probably a good thing to know something about it...

That chown thing mentioned above was of course never intended as a lasting solution. I was just trying to get an error-message or something out of the system. All I got was the email. Not much..., but maybe it was enough to point me in the right direction.

I'll be back with more If I find a solution...

bomix · 03-03-2005, 03:45 PM

Having had a quick look at SELinux, I decided I don't really need it, so I disabled it and rebooted.
Unfortunately that didn't make any difference... I still can't get apache to execute the scheduled jobs

I can create the jobs and the jobs seem to be executed. The jobs disappear from the queue at the right time, but nothing really happens...
And I can't find any info in any apache logs or in the system log.

This is starting to annoy me now...

Does anyone know what kind of spells I need to cast here?

nomikos · 01-22-2009, 09:30 PM

Quote:

Originally Posted by bomix

This account is currently not available.

this is because apache does not have a shell assigned:
--> /sbin/nologin

----------------------------------------------------

1.- apache can run "at" command if is into /etc/at.allow
2.- check in /etc/passwd that apache can run shell commands:
--> apache:x:100:100:Apache:/var/www:/bin/sh

Guttorm · 01-23-2009, 10:42 AM

Hi

Take a look at /etc/at.deny - in that file you will usually the "apache user". If it's there, just remove the line.

On Debian/Ubuntu www-data is not allowed to use at by default. I don't know about Fedora. But a shell should not be required.

bomix · 01-23-2009, 01:02 PM

Hey, thanks for replying. Even if my question is almost 4 years old :-)
I think I ended up putting my "jobs" in a MySql database and having a python-program (in crontab, if I remember correctly) checking the database for new jobs on a regular basis.

Thanks guys :-)