Greetings. I've a weird problem - quota limits are not displayed in Statistics > Web quota. Nevertheless quota is working properly and user is not able to exceed it by any uploads. But I can see it from shell: Code: # quota -u web1 Disk quotas for user web1 (uid 5004): Filesystem blocks quota limit grace files quota limit grace /dev/mapper/vg_hosting-lv_root 297524 512000 513024 365 0 0 297 of 500 MB are used by web1 user. By du -hs I can see the same 297 MB, so it's ok here. The repquota -avu commad shows the following: Code: # repquota -avu *** Report for user quotas on device /dev/mapper/vg_hosting-lv_root Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 1817652 0 0 74740 0 0 bin -- 2120 0 0 107 0 0 daemon -- 332 0 0 41 0 0 vcsa -- 8 0 0 1 0 0 qpidd -- 40 0 0 9 0 0 postfix -- 412 0 0 128 0 0 ntp -- 12 0 0 3 0 0 mysql -- 588724 0 0 987 0 0 named -- 116 0 0 25 0 0 apache -- 528 0 0 130 0 0 webalizer -- 16 0 0 4 0 0 ldap -- 168 0 0 23 0 0 Shader -- 87588 0 0 2147 0 0 vmail -- 428 0 0 108 0 0 clam -- 42480 0 0 10 0 0 amavis -- 4680 0 0 113 0 0 getmail -- 8 0 0 3 0 0 ispapps -- 24 0 0 7 0 0 ispconfig -- 30424 0 0 6633 0 0 web1 -- 297524 512000 513024 365 0 0 web2 -- 34532 51200 52224 4901 0 0 web3 -- 130184 307200 308224 878 0 0 web4 -- 534480 2048000 2049024 208 0 0 .... The repquota -avug has one additional information block with groups and all quotas for client1, client2, client3 etc groups are empty: Code: .... ispconfig -- 30440 0 0 6636 0 0 client3 -- 297524 0 0 364 0 0 client4 -- 34532 0 0 4900 0 0 client7 -- 130184 0 0 877 0 0 .... I have one big partition and here is /etc/fstab contents: Code: /dev/mapper/vg_hosting-lv_root / ext4 defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 1 1 UUID=fdba082e-df0a-4fb5-8201-30fae405ba1d /boot ext4 defaults 1 2 /dev/mapper/vg_hosting-lv_swap swap swap defaults 0 0 Quota files seems to be valid: Code: -rw------- 1 root root 12288 Jun 1 08:57 aquota.group -rw------- 1 root root 11264 Jun 1 08:57 aquota.user Code: # cat quotagrpadmins # # This is a sample groupadmins file (/etc/quotagrpadmins) # # Comments begin with hash in the beginning of the line # In this file you specify users responsible for space used by the group users: root mygroup: root How could I come up with fixing this to show HDD usage for administrator and users? After the detailed setup and bugfixes will be over, in acknowledgment of community's help I'll try to post my detailed step-by-step guide of ISPC installation with some advanced features, because I have all steps documented in internal wiki.
Which ispconfig version do you have installed? Have you changed anything in the ispconfig sources as there are no known problem with quota display in the current released version 3.0.4.5.
Oh, sorry, completly forgot to mention versions: CentOS 6.2 x86_64 2.6.32-220.17.1.el6 ISPConfig 3.0.4.5 Sources were not modified. I only modified mail templates in /usr/local/ispconfig/server/conf-custom/mail to make'em come from valid e-mail address.
Either your repquota output is differntly formatted so that the columns dont match or the ispconfig server script is not run once a minute by cron. ISPConfig uses the following command options to get the qwbsite quota usage: repquota -au and repquota -ag
Found it. Thank you for your help. The reason is concealed in my paranoia - I copied some settings of php.ini from other server and among them there were disable_functions with shell_exec(), system(), and passthru() being disabled. I should surmise that earlier.
The problem with centos is that it does not hafe different php.ini files for apache, cgi and cli like debian and ubuntu. ISPConfig requires exec functions only on the shell (cli), so you can disable exec functions for websites on debian and ubuntu in the cli/php.ini. But centos uses the same php.ini for cgi and cli, so you can not disable exec on centos for the websites easily to get the same security level then debian.
Thanks again for paying my attention to that. That's quite a problem, so I restricted all clients to use only CGI/FastCGI (I hope, my server will handle increased load) and added disable_functions to custom php settings for their websites. It was necessary to modify /usr/local/ispconfig/server/plugins-available/apache2_plugin.inc.php to make it. I know that modifing core scripts is a bad practice, but atm I didn't find any other way to restrict users from using exec() and other harmful stuff. While they can't read other users home directories (they have 710 perms), but they still can ls -l from /etc as long as it's 755 (I'm not sure, is it safe to decrease it). Now, without exec() and system(), users are binded to their directories. Upd.: Maybe I should think aboud mod_security, but it's quite greedy for system resources and very unfriendly in use. I was using it for a while with atomic rulesets, but didn't enjoy that experience =)
Fastcgi is the recommended php mode and it does not cause any increased load. Using mod_php is insecure and not recommended. For recommendations of php modes, please see manual. There are no modification sof the core scripts nescessary to achieve what you described above. Just add the disable_functions line in the custom php.ini field in the website settings.
But if client adds the new website on his own, then these settings won't appear unless administrator adds them from his account. My rude modification is forcing client's php.ini to contain disable_functions right when website is added (despite of who added it - client or administrator). Modifing core scripts is a mortal sin, but as long as I know, there's no master template for client php.ini, it's being built from /etc/php.ini + custom field contents.
There are 2 options to achiieve the same result without modifying a line of code in ispconfig: a) Create a new folder e.g. /etc/php5/custom/ and add a customized php.ini file there. Then login to ispconfig and go to System > Server Config > fastcgi and set the new folder there as path for the fastcgi php.ini file. For cgi.php click on the web tab of this form and add the path to the custom php.ini file there. b) Login to phpmyadmin, select the dbispconfig database, edit the database structure of the web_domain table and there the custom_php_ini field and add the disable_functions line as default value of the site.
Awesome. I considered invasion into DB structure would be the lesser evil, but still a mortal sin, so I've chosen the first path and it works great. Now I have separate php.ini files for ISPC and for users which are restricted to FastCGI. I can't even express the depth of my gratitude to you for help. Thank you.
