PHP Automated Administrivia?

wikinerd asks: "I am sure all of you know what PHP is and many of you may even use it on your websites, like me. Some of you may have read a this article from Linux.com article that gives some examples on how to use PHP to automate your server administration tasks (or to say it with one word: administrivia). I wonder whether there are any Slashdot users that have already used PHP in their administrivia, and what the results are. Is PHP appropriate for this task? If you have written useful PHP scripts, would you consider to publish their source code here? I am sure that posting your scripts can be beneficial to many new (and old) admins, so let's share our work!"

Comments

Lots of things

[Nos.]

I've used PHP to handle a lot of things to automate things. I've written a few different backup and restore type utilities - one for a webhosting company that allowed customers to restore directories and/or files on the fly from a 5 day rotating backup. I've used it for fairly simple tasks as well, such as monitoring databases for new and/or strange entries. I'm currently using it to pull information from the gameport (well, actually a binary polls the gameport) that is hooked up to some sensors around the house. Its on its way to becoming a home security system.

PHP is not a bad scripting language, though it is mostly used for web backends. I think a lot of admins are still more comfortable using something like PERL for these kinds of tasks

I use it...

[saintp]

...quite a bit. I used to be a web programmer before I started sysadminning, so I'm still more comfortable in PHP than in Perl. Consequently, I use it especially for automating database management tasks; I just find those easier to write in PHP than in Perl. For most simple administrivia, I'll just bang out a quick Perl script, but for those areas where I think PHP is stronger -- such as DBA tasks -- I'll switch into it.

Website Abuse Reporting

[Morgon]

I use PHP to handle common points of abuse (through worms or other related ignorance) and automatically run it through CRON on a daily basis to send that data off to the abuse accounts of the ISPs.

Incredibly enough, it HAS seemed to work. If only in the fact that I get few repeat IP addresses :)

In the setup I have, I use one script to catch all (via .htaccess redirects), with a MySQL backend to handle all of the data until cron.daily takes care of it.

You can find it at http://www.morgontech.com/abuse/

Use the tool that works

[gabe]

The tool that works for us is PHP. Our entire codebase is PHP. We use PHP on the CLI heavily (cron jobs, manual tasks, etc.) because we can simply use the exact same codebase for those tasks as well as our website. Why would I go out of my way to reimplement our business logic in another scripting language simply because it's "more suitable" for the command line?

Granted, if your products/systems don't use PHP to begin with, I'm not sure why you'd be using on the command line. If you use Python, I'd expect you to use that for your cron jobs also. Same goes for Perl, Tcl, Ruby, etc.

The only downside to PHP CLI is that it is not usable in the sense of a shell. You can't launch PHP CLI and then type in statements and have them executed as you enter each one. The Zend Engine takes your code all at once, parses, compiles and then executes it. So, for automated, periodic tasks, it's great. For on-the-fly scripting, it is slightly annoying to have to open up an editor, write a script, save it, and then run it. But that's such a minor annoyance that it's barely noticeable once you're used to it.

PHP has a niche

[aminorex]

The niche for PHP is people who have no time to learn Perl in order to write web pages. PHP was designed to require as little mental effort and capability as possible. If that's what you're optimizing for, it's a good choice, regardless of whether the task is administrative or application-oriented. If, on the otherhand, you have actual knowledge of a programming language, or are willing to learn one, then the PHP option loses all of its appeal. The problem is that once you write something in PHP because it's a quickie, suddenly you've got an installed legacy base of PHP code, and before you know it, you're a "PHP shop", and then you're truly scrod (a breed of Atlantic whitefish, I think).