Michael, > 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? >> >> [r...@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. As you predicted...I'm fine again. These tools worked exactly as described. Thanks _______________________________________________ Blueonyx mailing list [email protected] http://www.blueonyx.it/mailman/listinfo/blueonyx
