I'm sure this is something specific to just me, because it involves a custom hook. But I suspect that the changes to hook event variables is causing this problem. I'm not sure how to resolve this.
I have a pre_hook - /usr/local/directadmin/scripts/custom/domain_destroy_pre/default_domain.sh - the purpose of which is to prevent end-users from being able to delete their default domain name. (This is so that if they want to delete their default domain, they have to ask us first - that way we don't run into issues where our billing saying their domain is one thing and the domain on the server saying something else).
However, if the domain is being deleted as part of the overall account being deleted (by the admin user or reseller) then this delete needs to be processed.
The code for the pre hook was:
When deleting an account as an admin or reseller user, the ${creator} environment variable - prior to 1.674 - was present.
When deleting an account as the end-user, the ${creator} environment variable - again, prior to 1.674 - was not present.
There was actually a number of additional environment variables present when the domain was deleted as part of the admin/reseller deleting the account - I just chose ${creator}.
This is essentially saying if the ${creator} variable is not present (this would mean that it's an end user calling the deletion), then check to see if the domain being deleted is the default domain. If it is, then return an exit code of 1 (to prevent the deletion from happening) and tell the user they can't delete their default domain.
If the ${creator} variable is present (meaning this is an admin/reseller deleting the domain - I think the only way this would be possible is through deleting the whole account) then just ignore all of this, the pre-hook exits normally with a 0 code.
This allowed me to differentiate between how the domain was being deleted.
Unfortunately now - starting with 1.674 - the environment variables passed to this pre-hook are the same regardless of how the domain is being deleted.
The account still gets deleted if the admin/reseller deletes the domain... but because this pre-hook is actually failing remnants of the domain remain on the server (i.e. it still exists in /etc/virtual/domainowners after the user's been deleted... there may be other areas where it's not cleaned up).
Again, I know this is probably a specific issue tied just to me. I'm not asking you to fix this just for me - although I would be open to any suggestions on how this logic could be applied in a 1.674 environment going forward.
I think from a broader point of view, when you cleaned up the environment variables being passed to all of the hooks - do you need to pass something to identify what user-level actually initiated what is calling the hook? While this specific issue may just be applying to me, I have to wonder if there are other DirectAdmin users that are needing their hooks to be differentiated based on what user-level is calling the hook. I get wanting to clean up the environment variables being passed. But I think there needs to be something passed along to all of these hooks that identifies what user-level initiated the action that's triggered this hook.
I have a pre_hook - /usr/local/directadmin/scripts/custom/domain_destroy_pre/default_domain.sh - the purpose of which is to prevent end-users from being able to delete their default domain name. (This is so that if they want to delete their default domain, they have to ask us first - that way we don't run into issues where our billing saying their domain is one thing and the domain on the server saying something else).
However, if the domain is being deleted as part of the overall account being deleted (by the admin user or reseller) then this delete needs to be processed.
The code for the pre hook was:
Code:
if [ -z "${creator}" ]
then
if [ "$defaultdomain" = "yes" ]
then
echo "Cannot delete the default domain";
exit 1;
fi
exit 0;
fiWhen deleting an account as an admin or reseller user, the ${creator} environment variable - prior to 1.674 - was present.
When deleting an account as the end-user, the ${creator} environment variable - again, prior to 1.674 - was not present.
There was actually a number of additional environment variables present when the domain was deleted as part of the admin/reseller deleting the account - I just chose ${creator}.
This is essentially saying if the ${creator} variable is not present (this would mean that it's an end user calling the deletion), then check to see if the domain being deleted is the default domain. If it is, then return an exit code of 1 (to prevent the deletion from happening) and tell the user they can't delete their default domain.
If the ${creator} variable is present (meaning this is an admin/reseller deleting the domain - I think the only way this would be possible is through deleting the whole account) then just ignore all of this, the pre-hook exits normally with a 0 code.
This allowed me to differentiate between how the domain was being deleted.
Unfortunately now - starting with 1.674 - the environment variables passed to this pre-hook are the same regardless of how the domain is being deleted.
The account still gets deleted if the admin/reseller deletes the domain... but because this pre-hook is actually failing remnants of the domain remain on the server (i.e. it still exists in /etc/virtual/domainowners after the user's been deleted... there may be other areas where it's not cleaned up).
Again, I know this is probably a specific issue tied just to me. I'm not asking you to fix this just for me - although I would be open to any suggestions on how this logic could be applied in a 1.674 environment going forward.
I think from a broader point of view, when you cleaned up the environment variables being passed to all of the hooks - do you need to pass something to identify what user-level actually initiated what is calling the hook? While this specific issue may just be applying to me, I have to wonder if there are other DirectAdmin users that are needing their hooks to be differentiated based on what user-level is calling the hook. I get wanting to clean up the environment variables being passed. But I think there needs to be something passed along to all of these hooks that identifies what user-level initiated the action that's triggered this hook.
