DirectAdmin 1.674

[sparek]

We see that since 1.674 a lot of our actions in DirectAdmin hooks are failing due to lack of information about the user and creator. This was previously available in many hooks as environment variable.

We use this information to store data and preform (security) checks on external systems which are part of the hosting platform. As some hooks run before the user.conf is populated we rely on the information we get from the hooks.

Can this be restored?

This would make the hooks more useful again for all kind of integration cases and checks.

I had a similar issue:

S

Thread 'Environment Variables / Custom Hooks - DA 1.674'

Mar 17, 2025

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.

Version 1.674 | Directadmin Docs

DirectAdmin Knowledge Base

docs.directadmin.com

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...

• sparek
• Replies: 1
• Forum: General Technical Discussion & Troubleshooting

Was told that "the hooks don't have this variable" despite the information being present prior to 1.674.

I suppose the explanation is "it was never supposed to be there, therefore it was never there."

While I can certainly understand wanting to clean things up and developers perhaps never fully understanding how their misappropriations might be utilized by other users in the wild, but this also underscores having foresight whenever you develop something.

Certainly the DirectAdmin developers never intended for this information to be present in the hooks. But it was. And it was for a long time. Taking that information away is going to affect backwards compatibility moving forward. Ideally, this information leaking out should have been caught a long time ago and fixed and that would have lessened the impact of users in the wild utilizing the information in this leak. But also seeing this from the developer's side, I understand that bugs and unintended consequences aren't always found right away.

This is just an unfortunate event. I'm afraid that the full affects of this fix haven't been felt yet. I'm not sure what the solution is because I can see both sides. Perhaps a better notification of the effects of this change rather than a single sentence in the 1.674 changelog is needed.

 

[fln]

Can this be restored?

This would make the hooks more useful again for all kind of integration cases and checks.

Please let us know which hooks you would like to be extended to have additional tokens/variables. And what variables do you need in them? Our plan is to extend all the hooks to make sure you get the information hooks might need without reverting back to the previous mode where tokens/variables from one hook would leak into other hooks.

I'm not sure what the solution is because I can see both sides.

The plan is to collect feedback on what extra variables are needed and extend the hooks to include it. That way we can be sure these variables will always be present. In the old DA, some variables might be absent depending on what other hooks you have enabled or not. This is because if the hook is not enabled (the hook script file is not created), the DA would not collect the variables needed for it, and they would not leak into the next hook.

 

[exlhost]

Hi @fln , could you please bring back the OS updates option via Custombuild? It saves a lot of work and is extremely convenient for updating any OS.

 

[fln]

A new version is released with the following changes is released:

• Fixed Dovecot configuration when ssl_configuration=old is used in the CustomBuild options.conf.
• Enable PHP ioncube loader extension compatibility with PHP 8.4.