Solution to Disk Useage Prob when files owned by user nobody

I've written a perl script that I'm going to set up in a cron job that calculates the disk usage for each account and emails me if the account is over quota. I've done this because of that bug in cPanel that doesn't count files owned by the user "nobody" in the user's disk space usage. I'm tired of dealing with this problem, and I'm claiming my disk space back!

I'm also putting it in the public domain so that all of you can benefit from the work I've put into this. There are a couple of settings to change. Look for this section:

Code:

######## SETTINGS - EDIT BEFORE USE ########################

$to_email = 'user@domain.com';
$from_email = 'root@server.hostname.com';
$path_to_userdir = "/home"; # no trailing slash
$whm->{host} = "11.111.11.111";
$whm->{user} = "root";
$whm->{accesshash} = "360eddf2dc1097a0afb95cabd0aa48fe
15b8be49c79051a25b4cf33c7c9ff226
286fb7f77f693a2dfcb3c61f0612835a
9a94e1b122efe162d86b2a0063ba8ff3
e79f2a4603429476d900393807bef375
916111997b48699aba010f04506aab2a
5abb09a102c9ebe95ca143888f552325
545e55aa4173e6bab040ec963806bcbf
9a9f3c9185a1e6f67c5b2dae9c697d59
238725d21124eba093647b13986528c4
2b629b5e0bc96c46337172a72081360c
c7654f47e976318a43ab822795b57f30
a2ef3ebde7a9a914e76ede61e6ff80dd
c7e08c099bf3eb41fefa6c6ca9737e23
650e6fd5323563c8f519a015b5c8a65c
80692547f1fd46753b1162421f651645
7008ab878ae2380322cd01cf65ab26ba
bc6c58d0b962e66667e1076b5b917e0a
43bced5ad268c3024fc2a5be4c4aa4b9
e21afb4dcef4b4892f336bf49a2b6bd8
66ba9cfa74086eddb962fb81a592ec9e
e0e3078c6d2efa02fa039fe4686fd73a
43d64b0e6a42e4891cbdc206faa7599e
14bd26082a84d38e8ad7df4d05e3cb4e
c8f8651ca9f24528953c2526833da7e1
a99fec7feb8e09c963490b0b54a53204
4c1f14f034276ab6c5682eb00ad24318
7bea6452f143d103518721b291e4a7c6
3c83e053aa11288ead6323c22f0555ac";
$whm->{usessl} = 1;

##############################################################

$to_email is the email address you want notifications sent to. $from_email is the email address you want the emails to come from. This one doesn't have to be a valid email address. I use root@myhostname.com so that I know which of my servers the account is located on. $path_to_userdir is the path from the root of your server to your user's home directories NOT their dataroots! So if "foo" is a user on your server, and their dataroot is /home/foo/public_html, then your $path_to_userdir setting should be "/home" without a trailing slash. $server is your hostname. $sendmail is your path to sendmail. This is most likely "/usr/lib/sendmail" or "/usr/sbin/sendmail." $whm->{host} is your server's ip address. $whm->{user} is the administrative user you are using to connect to the cpanel data. $whm->{accesshash} is the remote access key. You can get your remote access key by logging into WHM and clicking on "Setup Remote Access Key." $whm->{usessl} doesn't really matter because you're connecting to localhost - this script cannot work remotely because it uses system functions. Also, this script only works on *nix servers.

Then just upload this script to your server. Make sure you rename it to .pl instead of .txt and give it 755 permissions. I had to name it .txt so I could attach it here. Add it to your cronjob. Run it at least once a month. You should start getting emails notifying you when your users are going over quota, even when WHM doesn't report that they are over quota because of that pesky "nobody" issue.

Also, depending on how you name your packages, you may need to edit the regex on lines 71 and 75. These regex currently correspond to the way I do my packages, which all start with the number of MB the user is allowed, such as "1000MB Account." If you have a different scheme for naming your packages, you will need to edit this regex accordingly. If you don't put the disk space allottment in the name of your package, I'm not sure if you can use this script. I'm using the CPanel::Accounting perl module, and there isn't an account query function to get specific data other than the domain, username, package name, and account owner.

I make no warranties to the security of this script. As with all scripts and open source programs, I encourage each of you to inspect the script before running it on your servers. Also, if you would be so kind to let me know if you find any errors that should be fixed, I would greatly appreciate it!

 

The answer to that is terribly obvious. It breaks certain php scripts. WikiPedia and Gallery are two examples off the top of my head that do not run under phpsuexec without modification. Wikipedia has a configuration option that is supposed to make it phpsuexec compatible, but it doesn't work well. I have several servers that run under phpsuexec and several servers that don't.

Yes, I admit that I misspoke when I said it was a bug.