Sexifying WHM with XML API

Posted by Nessa | Posted in uncategorized | Posted on 07-06-2008



I don’t know about you other cPanel system admins out there, but I find WHM to be very useful for the more advanced and time-consuming tasks, such as installing SSL certificates. However, the easy stuff like changing an account’s package and resetting passwords is a royal pain in the ass as far as convenience is concerned when you have to log into WHM, list accounts, and make whatever change.

I recently became favorable towards the WHM XML API functionality which will let me do a majority of the everyday account-related tasks from command line without ever opening my browser, which is a lot easier when managing thousands of users across multiple servers. Below are a couple scripts I’ve put together using the XML API from a base script in the cPanel forums:

Change account password

Change account package

Both are run via command line, and the arguments passed to the PHP script as variables. For example, to change an account’s password:

./chacctpass myuser mypass1234

Customizing these scripts to perform different functions is easy via the following steps:

- change if ($argc != 3) to the number of command line arguments you wish to pass to the script plus one. In the above example there are two arguments and since the script name counts, add one and that makes 3.

- in the section where the arguments are assigned to variables (like $cpuser, etc), name your variables. The first one should have an array value of 0, then 1, 2, etc.

- edit the usage example, which will come up if the required number of arguments is not provided…you can add any text you like

- if you’re using a hash (which is more secure than user/pass authentication), go fetch your remote access key from WHM and put it in the $hash value within quotes, format intact. Otherwise, put in your WHM user’s username and password

- change the $server variable to your server’s hostname

- change $apipath to the WHM path for the function you are using. You can find a whole list of them here, and most will give you the path to use in the examples sections. In the API path, insert your variable names where the values are suppose to be. For instance:

$apiPath = “/xml-api/passwd?user=myuser&pass=mypass1234″;

Would be:

$apiPath = “/xml-api/passwd?user=$cpuser&pass=$newpass”;

In the header section, uncomment whichever $header .= “Authorization: line that matches your authentication method (user/pass or hash)

Once you’ve configured your API script, chmod to 700 and run from the command line as show in my example. It’s better to lock down the script by changing its ownership only to the user that will be using it, and not giving read, write, or execute permissions to anyone else.

Note: for these scripts to work you have to have PHP compiled with OpenSSL support, otherwise change the socket variables to http over port 2086.

How to Make Your System Admin Mad by Creating Huge-Ass Files

Posted by Nessa | Posted in Uncategorized | Posted on 31-10-2007


So If you’ve ever woke up in the morning and asked yourself…”Hmm, how can I make my system admin’s job harder to the point where they get mad and shut down my server?” Well, lucky for you I can answer that question. All you have to do is use the ‘dd‘ command to write a 120gb file to an 80gb hard drive. That’s a winner.

By ‘dd’ I’m not talking about my bra size, people. It’s sad, but we recently had an over-curious customer try to see what would happen if the hard drive filled up on his dedicated server. You know what happens when you flush a clogged toilet? Yea….

So here’s the command:

dd if=/dev/zero of=test bs=1024 count=125829120

This command will write a 120gb file directly to the disk. ‘of’ specifies the name of the output file, while ‘bs’ represents the size of a block and ‘count’ is how many blocks to create. Really, it’s a dangerous thing to do if you don’t know what you’re doing. Generally the only time I do this is when I’m testing large file support for servers and PHP.  Nevertheless, the sheer curiosity of ignorant users is enough for me to pull the power plug on a server.

Size Matters with PHP

Posted by Nessa | Posted in Uncategorized | Posted on 27-08-2007


I figured this might be helpful to post since it seems to be a fairly common issue poking up about PHP’s limits in regard to file size. It’s no secret to fellow programmers that PHP is incapable of readily handling files over 2gb on the typical 32-bit system, but others are easily aggravated with a greeting of errors that look like this:

PHP Warning: ……. failed to open stream: File too large in ……..

Generally I’d say that if you’re trying to get PHP to man-handle huge files you’d need to have one badass server that can take that kind of abuse. Before you go about trying to compile PHP with large file support, you may want to consider passing the ‘split’ command through the system or passthru functions to break your massive files into smaller bits so PHP can handle them. If you’re the type that has to go about everything the hard way, then I guess that’s why you visited my site.
To compile PHP with large file support, you need to add a simple compiler flag preceding your configure statement. This should look as so:

# CFLAGS=”-D_FILE_OFFSET_BITS=64″ ./configure –with-modules-that-i-use

Then your make && make install and (if all goes without error) you should now be able to work with large files with PHP.

Too bad nothing’s really straight forward, eh? Apache itself has a filesize limit too (even up to 2.2.4) so don’t waste your time trying to get your newly-compiled PHP installation to work with Apache. When I was first trying to work this out I figured that it’s best to have two PHP installations, one for Apache and the other just for the CLI.

To do this, create yourself a phpinfo file and copy the configure line, removing the single quotes from around each flag. Two things you’ll want to change though:

  • Remove the ”–with-apxs2=/usr/local/apache/bin/apxs‘ (or similar) flag to keep the installer from compiling against Apache
  • Change your –prefix to a different location. I used ”–prefix=/usr/php-lfs’ .

When the installation is done, make it easier on yourself by creating some symlinks to the new binary:

ln -s /usr/php-lfs/bin/php /usr/bin/php5

ln -s /usr/php-lfs/bin/php /usr/local/bin/php5

This way you have your LFS-compiled PHP version in /usr/bin/php5 to use for your scripts. To call them, you’d use:

php5 /path/to/script or /usr/bin/php5 /path/to/script

What if you actually want to call the script from a browser? Well, you still can’t load a large file in the browser itself, but you can process it through a script to have a process run on the server:

<?php passthru('/usr/bin/php5 myscript.php'); ?>

And that should pretty much do it.

Listing IP Addresses of a Server

Posted by Nessa | Posted in Uncategorized | Posted on 10-06-2007


I hate using the jarbled output of ifconfig to find out what ip addresses are active on a server, so using this complex command will list all the IP addresses of the server in a nice little list:

ifconfig | grep 'inet addr:'| grep -v '' | cut -d: -f2 | awk '{ print $1}'

I specifically use this command for a VPS setup script that I was working on to automatically input the correct server IP into the httpd.conf and named entries on cloned systems, so I don’t have to do it manually. To do this you would just assign the command as a variable, then call that variable with the replace command:

IP=`ifconfig | grep 'inet addr:'| grep -v '' | cut -d: -f2 | awk '{ print $1}'`
cat httpd.conf |replace 123.456.789.123 $IP --httpd.conf

If you want to incorporate this into a PHP script, you just need to use the system() function, assuming your host allows it:

<?php system("ifconfig | grep 'inet addr:'| grep -v '' | cut -d: -f2 | awk '{ print $1}'"); ?>

Creating your Own “Access Groups” In Linux

Posted by Nessa | Posted in Uncategorized | Posted on 22-05-2007


We started cracking down a bit on system binaries being executeable by end users on our shared hosting servers, which consisted of chmod-ing things like ‘wget’ to 700 so only root users have access. If you’re on shared host, it’s likely that you’ve encountered this kind of restriction before, and if you’re a server admin you probably know why this is necessary.

A typical scenario I’ve seen in many cases is some user’s crappity software gets exploited and executes the ‘wget’ command to download hacks and warez onto the server. I’ve also seen typical Linux functions be abused by hack processes because the access was not being controlled — it’s only safe to say that certain system binaries should be restricted to only trusted users….programs that I find particularly pervious to hacks are those like wget, lynx, scp, sh, and exec.

The issue with this (and the point of this article) is that if you suddenly disable these functions you’ll probably find yourself with a dozen complaints from your users who were using them. I’m all about fairness, so I’m not about to tell someone to rewrite their scripts because of a server-side change. Instead, I created a group on the server and added those users to be able to have access to what they needed, and chgroup-ed the binaries to that group.

I’ll use the wget example first. Say you have ‘user1‘ and ‘user2‘ that both need to be able to use wget, which is currently set to root:root 700. You’ll need to first create a file called ‘’ and insert this script:

if [ $# -ge 2 ]; then
if [ $UID == 0 ]; then
egrep ^$1 /etc/group > /dev/null
if [ $? == 0 ]; then
while [ $# -gt 0 ]; do
echo $GROUPNAME `groups $CURRENT` |sed 's/.*: //g' | sed 's/ /,/g' | usermod -G `cat -`,$GROUPNAME $CUR$
echo "the group $1 does not exist."
echo "you must be ROOT to run this script."
echo "usage: $0 grp usr1 [usr2 ... usrN]"

I know, I know, you’re probably asking why I dont use useradd +G or something like that. I tried, but in this case those commands are not appropriate. Anyways, go ahead and create your group:

root@vps [~]# groupadd wgetters

Now, simply run the script and add your users to that group:

root@vps[~]# sh wgetters user1 user2

Run id user1 to make sure that user was added to the group — you should see something like this:

uid=32010(user1) gid=32012(user1) groups=32012(user1),32014(wgetters)

Now if you chown the wget binary to root:wgetters / 750 , then only the users in that group can use wget, and their actual group identity would be unaffected.

It wouldn’t hurt mentioning that wget is often unnecessary, as many scripts can be run other ways:

php -q scriptname.php

perl scriptname.cgi


lynx (assuming that you have lynx enabled)