Reseller Stats wrong allocation info

[sparek]

If I set up a reseller and then from that reseller set up two users, each with 500MB of bandwidth and 100MB of disk space


So I've allocated out 1000MB of bandwidth and 200MB of disk space, correct?

The Reseller Stats reports the correct bandwidth allocated, but the wrong disk space:


Where is it getting the extra 50MB for disk being allocated?

 

[sparek]

I've tracked this down to a "bug" or oversight in the /usr/local/directadmin/scripts/user_to_reseller.sh script.

It does not check the DirectAdmin config variable reseller_allocation_include_self and assumes that reseller allocation will include self, so it prefills /usr/local/directadmin/data/users/%reseller%/reseller.allocation with disk and bandwidth already assigned to %reseller% when %reseller% is converted to a reseller.

This apparently gets all sorted out when the daily tally runs - action=tally&value=all - although, I'd prefer something that can rebuild the /usr/local/directadmin/data/users/%reseller%/reseller.allocation file without having to run tally for all users. But I haven't figured out what that is, or even if such a command exists.

It would appear that moving another user into a reseller doesn't trigger a rebuild of the /usr/local/directadmin/data/users/%reseller%/reseller.allocation (either through the /usr/local/directadmin/scripts/move_user_to_reseller.sh script or the CMD_MOVE_USERS API). So this needs to be done manually after moving an account to a reseller. I can script something to do this, but I'm wondering if there is a more eloquent way already built-in to DirectAdmin to accomplish this, since I know action=tally&value=all will do this, I just prefer not to run tally for all users after creating a reseller.

 

[Richard G]

I just prefer not to run tally for all users after creating a reseller.

It seems that one can also run the tally for a single user or list of users, found it in a post from 10 years ago, but as far as I know still works.

echo "action=tally&value=freddy&type=user" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq d
here the username freddy is used as example.

Maybe you can use that for your needs?

 

[sparek]

Admittedly, I didn't try that specific syntax.

I thought writing to /usr/local/directadmin/data/task.queue had been superseded by running a task directly with the directadmin binary.

I tried:

/usr/local/directadmin/directadmin taskq --run="action=tally&value=%reselleruser%&type=user"
/usr/local/directadmin/directadmin taskq --run="action=tally&value=%reselleruser%&type=reseller"
/usr/local/directadmin/directadmin taskq --run="action=tally&value=%user%&type=user"

Where %reselleruser% is the username of the reseller and %user% is the username of the user that was just added to %reselleruser%

None seemed to work.

But the fact that action=tally&value=all works, would seem to indicate that SOMETHING is running during that process that resets /usr/local/directadmin/data/users/%reselleruser%/reseller.allocation but I just don't know what or if it's granular enough to actually run separate.

Instead I started working on a script that iterates through /usr/local/directadmin/data/users/%reselleruser%/users.list and grabs the respective quota and bandwidth values for those user's user.conf file and keeps a running sum of each. Then updates /usr/local/directadmin/data/users/%reselleruser%/reseller.allocation with these new totals. Once I got started, work went pretty fast, so I'm just using that for now.

 

[Richard G]

but I just don't know what or if it's granular enough to actually run separate.

normally if you're fast enough (or process slow enough) you should be able to see what commands are done in the /user/local/directadmin/data/task.queue process.

You might be correct that the command is superseeded, however I still use that way to write to task.queue for synchronising DNS if that needs to be pushed over to the other server in the multi-server setup.

Unfortunately I don't know scripting, so I have no real solution for you.
But seems you found a workaround. Nice!