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. -- With best regards Michael Stauber _______________________________________________ Blueonyx mailing list [email protected] http://www.blueonyx.it/mailman/listinfo/blueonyx
