|DirectAdmin has numerous features that allow the admin to change how it looks, what it can do, and how it does things.|
The areas that can be customized are:
These allow the easiest form of control over what the User physically sees. This is good for basic hiding of features, or removing links to areas that you've disabled (if not already hidden). A good starting place to create your own skin is to copy ours, eg:
Note that the skins support embedded scripting (php, perl, etc.. whatever you want), as well as a basic if-then-else system allowing for a "more efficient" method of checking variables and controlling what data to show.
Relating to skins are the lanuage packs.
Also, if you want to change the display of one of DirectAdmin's hardcoded items, like a table, you'd have to use this guide.
To change the appearance of the login page, see this guide.
To change one page of a skin without copying the entire skin, and have the changed safe from update overwrites, use this guide.
2) Pre/Post sh scripts
The pre/post sh scripts are "hooks" which you can create for most common functions that DirectAdmin does. For example, when creating a DirectAdmin User, if you wish to add some extra functionality, you can use the user_create_post.sh to add code to perform some function with root access. A you might have guessed, the post scripts run after that task, and the pre scripts run before the task. The pre scripts are handy because if you exit the script with a non-zero return code, DA will halt and not execute that task.
There are numerous scripts available. Search the versions system for the list of avaiable scripts:
List of *_post.sh scripts
List of *_pre.sh scripts
There are also numerous examples on how to use these scripts in the KnowledgeBase.
Post.sh script examples
Pre.sh script examples
For that extra level of control, we created the all_pre.sh and all_post.sh scripts. These are run after all CMD functions, if those scripts exist. Using these should only be used for tasks that are either do not have their own specific pre/post script (above), or when their purpose is more of a broad range, like IP or username filtering for complete blockaged, or to even just allow certain users access to certain functions. The all_pre.sh is what you'd use to disable a list of functions that DA can do. So if you're disabling functions in step 1) by editing the skins, it's also a good idea to block that CMD in the all_pre.sh so the User cannot just type in the command manually. The all_pre.sh should only be used when needed because it would be run for all CMD scripts which is less efficient than DA just checking for the related pre/post script for that function.
By default the all_pre.sh and all_post.sh scripts only run on pre-defined CMD functions in DA. If you wish to block HTM files, you can enable that functionality with this option. Note that you can create your own HTM files, but you cannot create your own CMD calls. For this reason, enabling this feature will allow you to create your very own core functionality to DirectAdmin with root access.
3) commands.allow and commands.deny
The commands.allow and commands.deny files are per-User files that let you specify which commands you wish to allow, and/or deny for a User.
The functionality is similar to the all_pre.sh script, but without the ability to check the values of variables.
It's much simpler in that you just drop in command names, so there is no need for scripting.
There is also a feature (as of DA 1.40.2) called Login Keys
The Login Keys feature allows one account the ability to have multiple passwords to login. However, these new passwords can be heavily restricted on several criteria, including it's own commands.allow/deny files, connecting IP, expirty, and number of uses.
Plugins are scripts which you create, allowing you to let your Users to do tasks, but only with the process level of their own user ID*.
The main benefit of plugins is their ability to be installed with 1 click, work on any OS, any Skin, without needing to do any other modifications to your setup. They're also "safe" in the sense that the calls made by a plugin run only as the User, and not root.
*You can get root access with a plugin if you create a plugin binary with chmod 4755, but can be a huge security risk if done incorrectly, so not usually recommended unless you're completely confident in your security-coding abilities.
5) DirectAdmin API
The DirectAdmin API is a tool that lets your own scripts connect to DirectAdmin to perform certain tasks. The scripts can be local or even remote relative to the DirectAdmin install. The scripts would essentially be an imitation of a web browser, in that the calls made to DA with the CMD_API functions will pass the data in the same format as a browser (99% of the time). The only difference between CMD and CMD_API calls is the data that DirectAdmin returns is parseable. Be sure to search the version system for a listing of all API commands because not all CMD_API commands are listed in the api.html page.
6) Custom Package Items
Custom Package Items let you add options to all Reseller/User packages. They can be any of the typical input types.
You can then combine the post.sh scripts such as user_create_post.sh and user_modify_post.sh to do thing like take action based on these custom package items.
These items will be saved into the reseller.conf and user.conf files, so you scripts can look in there for which actions to take.
7) General DirectAdmin Options
There are hundreds of options for DirectAdmin, each to accomplish a different functionality. Please be very careful if you chose to make changes to your directadmin.conf. Always make not of what you add or change, and what the previous value was, in case you need to undo your changes.
|Creating a Login Key to use with your API, script, or temporary login, to keep your password safe|
© 2018 JBMC Software, Suite 173 3-11 Bellerose Drive, St Albert, AB T8N 1P7 Canada. Mon-Fri 9AM-5PM MST