DirectAdmin 1.644 RC

fln

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,168
Hi everyone!

We are happy to announce the release of DirectAdmin 1.644 RC.

This is a maintenance release focusing on fixing stuff and continuing with our planned changes. There is a big change in Evolution login page inner workings, but they are not visible.

Release Change log can can be found here:

DirectAdmin 1.644​

The update should be automatically available for all installations subscribed to the beta release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks
 
I noticed in the change log:

Usage of login_pre.sh, all_pre.sh, all_post.sh hooks are discouraged. For backwards compatibility reasons these hooks will be called but only by the old DirectAdmin commands.


In the past all_pre.sh could be used for
* denying a command (like CMD_API_ACCOUNT_ADMIN /CMD_ACCOUNT_ADMIN )
* limiting access to an admin account per ip address

Is there anything that now supersedes this for a similar function?
 
Can I disable password logins as the admin user to force only login keys?

And what about preventing the creation of a second admin user?
 
For user creation control you can use dedicated user_create_(pre|post).sh hook. It it not possible to disable the use of user password form shadow file, but you can just set it to a random value and forget it.
 
I'd really prefer to keep a method to do some type of limiting. I understand we can do a password and forget it - but I feel much better knowing right now admin users are restricted by ip either with a password or a login key. For me security is a chain - I don't actually use passwords to access directadmin and do set random long password - but the ability is still there to login with a password. Removing all_pre.sh with out a replacement opens up the ability for a login as admin to any ip again and, no ability to prevent password access. Taking ssh as an example, I can limit by ip, force key only, change the port or firewall it all - all links in a security chain. Since users need to access directadmin I have to keep 2222 open, that has the ability to access as an admin user and right now I can follow the previously documented all_pre.sh for this. A basic example that was used in the past was



Code: 
#!/bin/sh

#https://help.directadmin.com/item.php?id=350
# prevent creation of another admin account
if [ "$command" = "/CMD_API_ACCOUNT_ADMIN" ]; then
    echo "Cannot use this command";
    exit 1;
fi
if [ "$command" = "/CMD_ACCOUNT_ADMIN" ]; then
    echo "Cannot use this command";
    exit 1;
fi

#https://help.directadmin.com/item.php?id=349
# limit ip
USERTYPE=`grep usertype= /usr/local/directadmin/data/users/${username}/user.conf | cut -d= -f2`

if [ "${USERTYPE}" = "admin" ]; then
    for ipadmin in ip1 ip2 ip3 ip4; do
         if [ "$caller_ip" = "${ipadmin}" ]; then
                exit 0;
            fi
       done
   #repeat the check on the IP as many times as desired.
   echo "IP $caller_ip is not allowed to be logged in as an Admin";
   exit 1;
fi


For my own staff, vpn's are used. I know the range of ips that should have access, everything else I can deny. So even if someone had the correct password for whatever reason, it would be prevented. All_pre.sh also has the benefit of if there was some type of security issue where a user is able to somehow elevate usertype and become suddenly admin, they are blocked if the ip is not in the list.
 
Yes. There are more hypothetical use cases which will not be supported :). Or will be supported in a different way. Key reasons for all_pre.sh deprecation:
  • Performance penalty for executing a shell for each request is too high. One shell script per page load was bad enough with legacy skins, but now with Evolution moving to a new API this causes multiple requests for single action amplifying the issue.
  • It was too easy to mess things up. It is better to have dedicated hooks for specific actions rather than universal ones.
Please note that this versions does not remove the hooks. It may look like it in the change-long since we used the removed tag. We are discouraging its use and saying new features will not be calling all_pre.sh.
 
fln said:
We are discouraging its use
Click to expand...
Understandable, but how can we do something like this for example?
This is our current all_pre.sh which prevents users to delete the public_html folder from the file manager.
Code: 
#!/usr/local/bin/php
<?
$command = getenv("command");
$button = getenv("button");
if (preg_match("/CMD_FILE_MANAGER/", $command) && $button == "delete")
{
  foreach ($_ENV as $path)
  {
    if ($path == "/public_html")
    {
      echo "Je mag de public_html map niet verwijderen!\n";
      exit(1);
    }
  }
}
exit(0);
?>

Do we have to put that in some other file? Or will this be obsolete/not possible after a certain while?
 
@Richard G (y) we have filemanager_pre.sh for this. But even if we did not, then it would be perfectly reasonable to request adding the required single action scoped hooks.

Our move away from pre_all.sh to more specific hooks is to stop paying price for each and every request and allow customizations to be called only when they needed.
 
Yes in forums, tickets or feedback system. What I meant was that we are not against adding more hooks as long as they work for one particular command or action.
 
Oke thank you! I did it like this, hope that's good?
<feedback request removed>
 
Last edited:
fln said:
Our move away from pre_all.sh to more specific hooks is to stop paying price for each and every request and allow customizations to be called only when they needed.
Click to expand...
So another words, if an administrator sees the need for a hook, they have to request that DirectAdmin developers add that hook, wait (hope) for it to get picked up in development, and wait for it to get released. What was a 2 second administrator customization becomes a 2 month wait and see.

I can certainly understand the performance impact of pre_all.sh, but removing things like this can also take a huge bite out of the ability of administrators to customize the product to fit their needs. It puts a burden on the DirectAdmin developers to make these events hookable. And it requires administrators to wait for that functionality to arrive in the product.

From my administrators point of view - the more I can do on my own the less I have to depend on other developers to add that functionality and the quicker I can get the functionality pushed out to my users.
 
@Richard G for this particular use case there is nothing for us to do. You can create this hook yourself since we have filemanager hooks already available. Just create a file /usr/local/directadmin/scripts/custom/filemanager_pre.sh with contents:

Code: 
#!/usr/local/bin/php
<?
$button = getenv("button");
if ($button == "delete")
{
  foreach (getenv() as $path)
  {
    if ($path == "/public_html")
    {
      echo "Je mag de public_html map niet verwijderen!\n";
      exit(1);
    }
  }
}
exit(0);
?>

And it will behave as expected.
 
@sparek this is the chance to reveal all use cases of all_pre.sh and create better implementations to achieve same effect. As you can see with the example @Richard G posted, some DA users do not know about more specific hooks, thus relying on all_pre.sh.

I think DA has a reasonable amount of hooks and any missing ones will be quickly discovered.

We strive to achieve good balance between flexibility and performance and reliability. With blanket solutions as all_pre.sh any change in how we process arguments for some command might silently break your scripts. With dedicated hooks we can treat them as part of API, meaning that we clearly define what variables are available for the hook and they will always be there. Even if we change how we accept parameters on the HTTP levels we can keep hooks API stable (by hooks API I mean what data gets exposed to the hook as environment variables).
 
fln said:
for this particular use case there is nothing for us to do.
Click to expand...
Yes I've seen the reques was removed. I was confused since you wrote
fln said:
But even if we did not, then it would be perfectly reasonable to request
Click to expand...
So I thought that it would be good to request anyway. My mistake.
I will use the solution given by you here, thank you!
 
Next update, will directadmin split page encode out to directadmin.conf ? so we can set utf-8 without edit skin files( for multi skin user & non-English users will more help too)
 
fln said:
@sparek this is the chance to reveal all use cases of all_pre.sh and create better implementations to achieve same effect. As you can see with the example @Richard G posted, some DA users do not know about more specific hooks, thus relying on all_pre.sh.

I think DA has a reasonable amount of hooks and any missing ones will be quickly discovered.

We strive to achieve good balance between flexibility and performance and reliability. With blanket solutions as all_pre.sh any change in how we process arguments for some command might silently break your scripts. With dedicated hooks we can treat them as part of API, meaning that we clearly define what variables are available for the hook and they will always be there. Even if we change how we accept parameters on the HTTP levels we can keep hooks API stable (by hooks API I mean what data gets exposed to the hook as environment variables).
Click to expand...

Yea, I really owe you an apology for that rant.

I did not know that the filemanager_pre.sh hook existed. I didn't know a lot of the hooks existed. But there is documentation of this at

Hook scripts | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com

Kind of frustrating that we have to go through and make changes to our existing hook scripts. But there is an extensive hook list and documentation.
 
You must log in or register to reply here.
Back
Top