Solution to Disk Useage Prob when files owned by user nobody

[fuzzymonkey]

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:

######## 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!

[chirpy]

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.

It's not a bug in cPanel.

That said, nice work for those that need it

[jackie46]

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.

Waste of time. Why dont you simply run phpsuexec. Then you wont have to waste time writing scripts.

[fuzzymonkey]

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.

[nettigritty]

It's not a bug in cPanel.

That said, nice work for those that need it

shouldn't cpanel account disk usage including files uploaded through php by a user in their space? a user could end up using all the space on the server and cpanel would show usage as a few MB. serious issue, ain't it? and no, enabling phpsuexec is not a solution.

[chirpy]

It can't. The files are not owned by the cPanel account, so the unix quota system doesn't atrtibute them to it. That's a flaw with php. phpsuexec is a solition, just not for you maybe. The best you could do is to write a cron job to chown nobody files under /home to the user account they are in, but then you have to be careful about permissions.

[Miss Jacky]

Would a script, changing uploaded files from 644 nobody:nobody to 664 user:nobody, make any sense as a "good" sollution for the quota system counting this files for disk usage but the web server still keeping permissions to manipulate these files?

[xanaduservers]

It can't. The files are not owned by the cPanel account, so the unix quota system doesn't atrtibute them to it. That's a flaw with php. phpsuexec is a solition, just not for you maybe. The best you could do is to write a cron job to chown nobody files under /home to the user account they are in, but then you have to be careful about permissions.

Yes it can by using the output from a du -sh instead of reading the total space of the users files read the space of the Directories.

Other control panels do this, just cPanel doesn't. So don't say they can't, they just don't.

[chirpy]

Yes it can by using the output from a du -sh instead of reading the total space of the users files read the space of the Directories.

Other control panels do this, just cPanel doesn't. So don't say they can't, they just don't.

Nope. That won't solve the problem at all since it won't charge the space used by the files to the unix quota system. All it'll do is show the amount of space used but won't prevent the files consuming disk space above and beyond their quota.

[Spiral]

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.

WRONG! Both WikiPedia and Gallery work 100% perfectly under phpSuExec without
any modifications to the program whatsoever!

I have personally used both WikiPedia and Gallery (and others) under phpSuExec
and I also know first hand it works perfectly as well!

The problem you are running into is just simply file permissions.

When you change to phpSuExec, you need to update the file permissions on
some of the files under that program because you can't have any globally writable.

When we setup a new server under phpSuExec, we will generally run a script to
globally update the file permissions of all files on all hosting accounts and
everything works beautifully. We have never had a single complaint from any
user about anything not working or any compatibility problems either!

[spearhead]

Correct me if I'm wrong, but I was under the impression that using mod_php would be less load on the box. Also, using a caching app (say something like eaccelerator) would lessen the load further.

I'm all for the php cgi on users. The benefits are numerous - but with 150 domains all using PHP (and mysql with many) I would expect mod_php to be worth the issues for the performance advantage.

Does anybody agree or am I just shooting myself in the foot by not using phpsuexec?