[BlueOnyx:06069] Re: Quota discrepancy

[Michael Stauber]

Hi Rod,

> I've noticed an odd discrepancy in the disk usage GUI for some sites on
> my BX server.  Full disclosure: the sites on this server have been
> migrated at least 3 times using the cmu tools
> (Cobalt->BlueQuartz->BlueOnyx->BlueOnyx on VM).  The GUI shows the
> 'Usage Logs" as not using any disk space although a simple 'ls -lh' of a
> site's log directory shows multiple megabytes.  In the example below I
> see the log directory owner is SITE5-logs, but the group is site4. The
> actual log files share the same mismatched owner/group.  I think this is
> the problem.  On a recently created vsite, the 'Usage Logs' usage show
> correct values.  If my supposition is correct, how do I fix this?
> 
> [root at hood admin]# ls -l /home/sites/www.weskefamily.com/
> total 32
> drwxr-xr-x  2 apache     site4  4096 Dec  6 05:05 awstats
> drwxr-s---  2 nobody     site4  4096 Aug  7  2002 certs
> drwxr-xr-x  3 SITE5-logs site4  4096 Feb 16  2010 logs
> drwxrwsr-x  2 nobody     site4  4096 Nov 29 16:33 users
> drwxrwsr-x 34 nobody     site4  4096 Dec  4 08:46 web
> drwxr-xr-x  2 apache     site4 12288 Dec  1 04:12 webalizer

Yeah, I see what you mean. You can fix those issues with the onboard tools of 
BlueOnyx. Some of them were created by me for those very issues.

Part of the problem is/was that Cobalts and thne BlueQuartz already did a 
somewhat freaky job when it came to user and group management. Doing a couple 
of CMU migrations then also usually made matters worse and suddenly you end up 
with a ton of quota and/or user/group problems.

So run the following commands on your BlueOnyx as root and it should all be 
fine:

/usr/sausalito/sbin/user_gid_fix.pl
/usr/sausalito/sbin/fix_user_UID_and_GID.pl

The above two scripts perform similar tasks. They go through all users and fix 
their UID and GID. The logfiles of a site will also be chowned to the correct 
UID and GID. However, files in the /web folder will NOT change their 
ownerships, as that often can cause issues with some web based applications.

/usr/sausalito/sbin/fix_user_suspension.pl

That script makes sure that system accounts and accounts of suspended users 
are locked, so that these accounts cannot use SMTP-Auth. Our CMU usually does 
this as well, but it doesn't hurt to re-run that script just to be sure.

/usr/sausalito/sbin/disk_restorequotas.pl

That script is a life saviour quota wise. It reads the quota information for 
groups and users from CODB and synchronizes all users and groups with that 
info. Means: If the GUI says that user "tom" has 200MB of allowed diskspace, 
but the system disk quota of "tom" is set to anything else, then the system 
quota will be set to what's configured in the GUI for said user.

Once you have run all those four scripts you should be fine again.

Afterwards go to the GUI, "Active Monitor" / "Diskspace" and check the quota 
information for sites and users. Find those users or sites that are over quota 
and fix their quota settings until they have as much space as they need to 
have.

-- 
With best regards

Michael Stauber