Not suspending at limit

so modifying the user through DA isn't setting up the quotas correctly, but doing it manually is?

John
 
DirectAdmin Support said:
so modifying the user through DA isn't setting up the quotas correctly, but doing it manually is?

John
Click to expand...

That's right.
I also created a new user and checked /var/log/directadmin/system.log and /var/log/directadmin/error.log in the hope to get some hints. Nothing.
Is it possible to turn on debug mode or soemthing to get output from external commands execution logged?

Thank you.
 
Hmm... here are the "quota -v steve" commands I'm doing before and after I change the Disk Space limit from 10 to 12 meg through the "modify user" part of the panel:
Code: 
[root@user]# quota -v steve
Disk quotas for user steve (uid 514):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
      /dev/hda6       0       0       0               0       0       0
      /dev/hda3    1520   10240   10240              27       0       0
[root@user]# quota -v steve
Disk quotas for user steve (uid 514):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
      /dev/hda6       0       0       0               0       0       0
      /dev/hda3    1520   12288   12288              27       0       0
What is his limit set to?

John
 
Here are results of quota -v username before and after modifying Disk Space Limit on my end:
Code: 
[root@~ webcart]# quota -v redguitars
Disk quotas for user redguitars (uid 1009):
     Filesystem   usage   quota   limit   grace   files   quota   limit   grace
              /       0       0       0               0       0       0
           /usr     146       0       0              36       0       0
[root@~ webcart]# quota -v redguitars
Disk quotas for user redguitars (uid 1009):
     Filesystem   usage   quota   limit   grace   files   quota   limit   grace
              /       0       0       0               0       0       0
           /usr     146       0       0              36       0       0
[root@~ webcart]#
[root@~ webcart]# /usr/local/directadmin/directadmin c | grep quota
quota_partition=/usr
[root@~ webcart]#

It looks like edquota is not executed at all.
 
The limit which I set via DA is between 99 and 102.
I always set it to a different number before resaving because I don't know whether you compare the old value and the new one before executing external commands ;)
 
Of course :)
It's a fresh install of FreeBSD 4.9 about 2 weeks old. I didn't change much.
Code: 
[root@/home webcart]# /usr/sbin/edquota
usage: edquota [-u] [-f fspath] [-p username] username ...
       edquota [-u] -e fspath[:bslim[:bhlim[:islim[:ihlim]]]] [-e ...]
               username ...
       edquota -g [-f fspath] [-p groupname] groupname ...
       edquota -g -e fspath[:bslim[:bhlim[:islim[:ihlim]]]] [-e ...]
               groupname ...
       edquota [-u] -t [-f fspath]
       edquota -g -t [-f fspath]
[root@/home webcart]#
 
Hmm... there arn't any debug methods that keep track of whats being run, but what can be done is the temporary replacement of the edquota program...

Code: 
mv /usr/sbin/edquota /usr/sbin/edquota.orig
vi /usr/sbin/edquota
#make it look like:
Code: 
#!/bin/sh

echo "$1 $2" >> /tmp/edquota.txt

exit 0;
Then chmod it to 755 and try it again. Check the /tmp/edquota.txt for any output. Also check the file for the owner in case it's being run by an unprivileged user. (I'll check the code)

John
 
Catch ya :)
Looks like a missing username:
Code: 
[root@/home webcart]# cat /tmp/edquota.txt
-e /usr:102400:102400:0:0
[root@/home webcart]#
 
On the second thought, it's permission issue :)

/usr/sbin/edquota should look like
Code: 
#!/bin/sh

#echo "$1 $2" >> /tmp/edquota.txt

echo "$*" > /tmp/edquota.txt

exit 0;

and then it shows up the correct line:
Code: 
[root@/home webcart]# cat /tmp/edquota.txt
-e /usr:103424:103424:0:0 redguitars
[root@/home webcart]#
[root@/home webcart]# ls -la /tmp/edquota.txt
-rw-r--r--  1 nobody  wheel  37 Feb 13 12:16 /tmp/edquota.txt
[root@/home webcart]#
but the file is owned by nobody.
 
Hello,

Alright. I'll have a look in the code. I think it's some differences between the systems.. It shouldn't be working anywhere as "nobody", but it is, possibly due to the actual user ID vs. the effective user ID.. freebsd probably uses the effective (which is nobody), while RedHat might use the actual (just the method DA uses to flip privileges for some functions). weird. Oh well. Should be available for the next release then (I'll probably get it out soon).

John
 
Disk quotas for user psgfotos (uid 575):
Filesystem blocks quota limit grace files quota limit grace
/dev/hdc1 3672 30720 30720 536 0 0
but DA told 3.52 MB in use :(

any tips?
 
deltaned said:
Disk quotas for user psgfotos (uid 575):
Filesystem blocks quota limit grace files quota limit grace
/dev/hdc1 3672 30720 30720 536 0 0
but DA told 3.52 MB in use :(

any tips?
Click to expand...

This is not official answer, but I don't see here any problem.
3672 in "blocks", 1K each means 3672/1024=3.59MB, which is a little more than 3.52MB. Please also note that quote shows number of allocated blocks used by files while DA (I would guess) shows the sum of file sizes. This explains the slight difference (3.59 vs. 3.52).
 
DirectAdmin Support said:
Hello,

Alright. I'll have a look in the code. I think it's some differences between the systems.. It shouldn't be working anywhere as "nobody", but it is, possibly due to the actual user ID vs. the effective user ID.. freebsd probably uses the effective (which is nobody), while RedHat might use the actual (just the method DA uses to flip privileges for some functions). weird. Oh well. Should be available for the next release then (I'll probably get it out soon).

John
Click to expand...

I am not exactly sure what you mean by that because once a program runs with effective user ID other than root, the only way to spawn process under different user ID should be with set user ID bit. Anything else would constitute security issue.

I initially thought that you might have a parent DA process run as root while child processes run as nobody and use IPC to execute priveleges commands by the parent process, but a list of directadmin processes shows that they all run as nobody.
 
Hello,

Hmm.. well I found that it wasn't setting the effective userid back to 0, so the next release the userid and effective user id will both be zero when the exec is done. Redhat doesn't seem to have a problem with it (although, one would think it should). The actually processes are just using the euid as nobody, but for required circumstances the privileges are completely dropped to prevent anything from happening (ie anything done by the user/filemanager, and also chrooted)

John
 
You must log in or register to reply here.
Back
Top