Administrator Technical Notes
Clarification of of the less-clear aspects of DirectAdmin
This document is not intended to provide a full description of every DirectAdmin feature. It's purpose is to clarify some of the less-clear aspects of DirectAdmin so that you are informed enough to modify certain features (we do not encourage or support modifications, however).
DirectAdmin uses the 'is-a' object oriented design for all types of User accounts. The base usertype is a "User". Users control the setup of the account and provide the base for all the configuration files needed for the control of the account. The UNIX user is created from this class, as well as SSH access, system quotas and system passwords. Basically, the User class does everything required for Users.
A Reseller 'is-a' User, meaning a Reseller inherits all attributes of a User, but it extends the User class giving it more features and tools used to do other things. The general definition of a Reseller is "one who creates Users". A Reseller can be responsible for many Users, while at the same time being a User himself. This means that while the extended Reseller features that extend the User class control the creation and deletion of new Users, the Reseller also has the features of a regular User, so he can still create domains and do things that Users do, all from the same account.
An Admin 'is-a' Reseller, meaning an Admin can do everything a Reseller can do, but has additional privileges to do such things as: the creation and deletion of Admins and Resellers, the control of system services, the monitoring of system usage and the viewing and control of the current version of DirectAdmin. Although Resellers utilize the User base for storing Reseller configuration files, Admin ALL share the same config files (normally in /usr/local/directadmin/Admin/). This means that any changes made to one Admin account will change all Admin accounts. This does NOT apply to the Reseller subclass of the Admin's data. For example, if one Admin creates Users using the Reseller portion of his account, another Admin will not see those Users in their Reseller panel. Admins will also control the adding and removal of IP aliases to the server. This will allow the server to be accessed using different IPs.
DirectAdmin pre-forks. This means that all children that will be taking requests are spawned before any requests are made. DirectAdmin starts by loading the number of children specified in the directadmin.conf file located in /usr/local/directadmin/conf. If the number of children becomes less than 2, it will increase the maximum number of children by one. If it hits 2 again, it increases again. This processes is repeated and a limit is set to 20 children. You can set more than 20 children in the config file, but that number will not be increased.
After a connection is made, the child waits for the request to be sent. Once this is done, all headers and data are parsed and sorted. A default timeout is set to 10 seconds (or whatever is set in the config file) before a timeout occurs and the process is stopped. For operations that require more time, that number is increased.
Authentication uses system passwords. In order for it to succeed, the User must exist in /etc/passwd file, the crypt()-ed password must match AND there must be a directory with that username stored in the users folder (/usr/local/directadmin/data/users). If any of these conditions fail, a 1 second pause is taken before the failure is sent. This is used to prevent hackers from pounding the server with password attempts. All login attempts are logged, and after 10 failed attempts, all attempts (IP and request) are logged in the security log. If/when a login is successful after a failed attempt, the number of attempts is stored in the login.hist file in the users config directory. It's up to the server Admin to view these logs and to take the appropriate actions.
After authentication, the command will be checked to see if the usertype is allowed to run it. If the command does not exist, or is not allowed, an entry is made to the security log recording the caller's IP and request.
If the request passes those conditions, the command is run and the results are stored. Each command has a designated web page (although this is often changed depending on the results) and each web page will have tokens (see the skins tutorial) to be filled. If the web page does not have the proper tokens, the results will not be filled.
The choice for running a command and then finding its web page vs. finding a web page and running the commands stored in it was made for a few reasons. The main reason is that this method should make it much easier to create skins, as no knowledge of built-in commands is required.
The task queue's main role is to run in the background and monitor system services. Every minute, the cron daemon runs the task queue causing it to check the /proc director to see if all essential services required for web hosting are running. If you do not wish for these services to be run, you can either shut them off through the "System / Services Info" link in the Admin section of the panel, or edit the file located at /usr/local/directadmin/data/admin/services.status, set the desired service to OFF (ex: httpd=OFF) and then manually stop the service (service httpd stop). Failure to change the services.status file will cause dataskq to start up httpd again, creating one very confused server Administrator.
If a service is found to be not running, the dataskq tries to start that service by running (for example) "service httpd start", where httpd is the service that isn't running. If that command doesn't return zero, the dataskq tries to restart it, in a hope that the shut down portion of a restart will enable the start up to succeed. If THAT command also does not return zero, all Admins will be sent a message notifying them that the service in question is not running, and immediate action is require on their part to get it running again. A notification message is only sent once per hour.
The task queue is also used to reload/restart system services after a User, Reseller or Admin has made alterations to their account configuration and a restart/reload of a system service is required. Since the taskQ is only run every minute, if multiple duplicate requests are made to a service, the request is only executed once reducing server load, and ensuring that services won't be restarted at the same time from two (or more) separate processes. When requests of different importance's are made, only the request of the highest importance will be executed. For example, if requests are made for httpd to reload and restart, only the restart will be executed, as a full restart encompasses the effect of a reload.
Another use for the dataskq is to count up all account usages and make the appropriate actions. Everyday all User accounts are "tallied" for disk usage, bandwidth etc.. and are stored in their user.usage file. Once the IUsers are tallied, the Resellers are tallied from their Users and the the Admins (as one) from the Resellers. This give a total usage for DirectAdmin on the server. These numbers can be compared to the numbers generated from "Complete Usage Statistics" for the network device and disk partitions in the Admin's section of the panel to see how much activity is non-DirectAdmin related. If the total bandwidth has exceeded 75% for Resellers and 80% for Users, a message is sent to them notifying them that this percentage of their monthly allotment as been reached, and based on this information, an estimate as to how long they have until 100% of their monthly bandwidth will been used up will be sent as well.
Every month, all User and Reseller accounts are reset back to zero using the task queue.
Vacation messages (for User e-mail accounts) are checked a few times a day to see if they should be enable/disabled.
Licenses and Program Updates are also done using the task queue. The dataskq will decide if an update is necessary and send a notification to the Admins containing the results.
The way the dataskq works, is all requests for the task queue are appended to the file located at /usr/local/directadmin/data/task.queue. When the dataskq program is run every minute, it checks for the existence of the file, reads it in and deletes it, executing the data that was read in.
The Admin Panel is where Admins go to control the Administrative part of DirectAdmin.
The creation of Resellers requires a few steps. You must first create a Reseller Package. Most options are quite straight forward. At the moment, the package manager does not check the options with the number of IP's given, meaning if you give the Reseller 0 IPs, and also say that the "Personal DNS's" use 3 IP's, it won't complain. However, when attempting to create a Reseller with that package, an error will be generated. The "Domain IP" ListBox on the "Create Reseller" page is only applicable the Reseller's domain. This means that if the domain is set to "Shared - Server", this does not mean that the Reseller has that IP to create his own User accounts with. Only if the "Share Server IP" is checked in the Reseller package, will a Reseller be able to do this. The "Send Email Notification" feature is used to notify Resellers when their account is created. Once the popup window appears, you will note that many there is a message with tokens (see the skins doc) embedded. These token are used to insert the Reseller data into the e-mail. You can use these tokens in any combination you wish, and can also add those tokens into subject line. If you need to know what tokens are available, simply click "Reset to Default" and take note of tokens there (words between pipes: | ). When all the data is valid, the result of the account creation will be displayed on the screen and a comments box is shown. Any comments you wish to enter about this Reseller can be entered and saved. The following paragraph also applies to the creation of Admins except that Admins require far less data and there are no Admin packages.
Reseller/User suspension will occur if either a User/Reseller has gone over their bandwidth limits, OR if an Admin/Reseller (respectively) suspends them. If the Reseller/User went over limit to become suspended, he will become activated when his account is reset on the first day of the next month. If the account was manually suspended by an Admin/Reseller (respectively), the account will remain suspended until it's activated again through the DirectAdmin control panel.
The IP Manager is used to control the addition of new IPs on the server and to assign them to Resellers. All the IPs listed in this menu will be loaded onto to the server at bootup using the "startips" script in the /etc/rc.d/init.d/ folder. When you add or remove an IP, the system is adjusted instantly. IP's can be shared, owned or free. If owned, that IP will be assigned to a User exclusively, and nobody else can use it for their domains. Shared IP's means that the IPs can be used among many Users for virtual domains (although, all owned IP domains are created using the virtual domain directive in apache anyway). A free IP is just that, free, meaning nobody is currently using it. An IP cannot be revoked from a Reseller unless it is free, or unless there are zero Users on the shared IP. Nameservers are completely independent from domains. A nameserver pair can be on any 2 IPs that do not currently have nameservers on them.
The "Complete Usage Stats" feature will show the server totals for all DirectAdmin Users. It also shows the transmitted and received data used by your network card, as reported by "ifconfig eth0". The disk partitions and their info are shown as printed by the command "df".
"Licensing / Updates" is used to show the contents of the license file and the version of DirectAdmin. It will also show the last time that both were updated. Although the links are provided, the main reason there were added was to enable you, the Admins, the ability to update the software on your own, in case it fails to do so on its own (might happen if your server is down when the command to update goes out, for example). You can manually update the software when you see that the version available is newer that the version you have, else it will simply give you an error message. Licenses, like the program, should update automatically. The license should attempt to update itself 3 days before expiry. It will attempt to update every day until the expiry. Once the expiry has arrived, if it has not updated, you have 5 days to manually update it before your DirectAdmin control panel will stop working. We give a 5 day grace period because payments can be are sometimes made late, due to unforeseen delays, which may not be the fault of the client.
If an Admin wishes to add an SSL certificate on the main server's domain, they must do it manually. To do this, the Admin must obtain the certificate and key (explained in just a moment). After these have been acquired, the Admin will have to edit /etc/httpd/conf/extra/httpd-vhosts.conf (or /etc/httpd/conf/httpd.conf with customapache) file and scroll to the very bottom. You should see 2 virtual host directives. With the one that says <VirtualHost <yourip>:443> you must modify the SSL tags.
Set:
and if provided with a CA certificate file add the following line (if missing), and put your ca bundle/chain into the server.ca file:
You have a few options when it comes to obtaining the key and certificate. First you can create you own self signed certificate. You can do this by using the following guide: http://help.directadmin.com/item.php?id=192
If you want to use an authority to sign your certificate (removes the annoying popup), you'll need to create a certificate request: http://help.directadmin.com/item.php?id=256
and you send the generated request text to to certificate authority to be signed. They will send you a signed certificate which you will install using the apache tags noted above (and you can delete the certificate.request file, it's not needed).
The Reseller Panel is where Reseller (or Admins) go to create/modify Users on the server.
The process for creating Users is very similar to creating Resellers. Once difference is that you specify which IP, of the ones you own, will be given to the User to use. The process for creating e-mail notifications is the same for Resellers.
The "IP Assignment" screen is used to determine what each IP will be used for. There are four main status levels: server, owned, shared and free. Server means its the server's main IP, owned means its assigned to one User only, shared means that many Users can use the same IP and free means its available to be set to shared or owned. You must decide what each IP will be used for before you attempt to create any Users. Once a User is added to an IP, that User must be deleted before the IP can be set back to free. Although the nameservers that are set to these IP's will be shown on this screen, you must use the "Name Servers" screen to create/modify them.
The Name Server's screen is quite simple to use in that each operation you do, you must first select 2 IPs. Once selected, you can choose the domain you wish to add the nameserver to, or delete the 2 nameservers from their IPs. When creating nameservers, if the domain is owned by the Reseller, his reseller.conf file will hold the new nameserver and any new Users he creates will be required to use that nameserver to register their domains. If a domain owned by a User is selected, that User's nameserver will change and they will be required to update their domain at their domain registrar. Any other domains for that User will not be changed. This also goes for other domains owned by the Reseller, in that only the domain selected will have its nameserver changed.
The skins screen is used to control the skin currently being used for both the Reseller and all of his Users. (Admin's are Resellers, so they do it from here too). The skins can be owned by either the server, or by the Reseller. A server skin cannot be deleted, while a Reseller skin can. If you want to test a skin before forcing it upon your Users, you can use the "Apply to Me" button to see what it looks like. This would also be applicable for skin testing. You can upload you skin packages (tar.gz format) using the "Upload New Skin" feature, which will store the skin files in your home directory: /home/username/skins , where changes can be made (see the skins tutorial). If you accidentally misconfigure the skin and cannot see what you are doing, simply run the command "/CMD_SKIN?reset" to restore the default skin. It is strongly advised that you do NOT edit the default skin, as you will not have anywhere to run when you misconfigure it. Also the fact that the server skins are overwritten each time the software updates should be a sufficient deterrent. Skins that Users use can manually be changed for each User by editing that User's' options under the "List / Modify Accounts" screen. This is appropriate when some Users want one skin, while others do not. You should note that clicking "Apply to All Users" will not care that some Users use different skins and will set it the same for everyone.
A Reseller can allocate more disk space to their Users than the total disk space they are allowed. This is because most often Users will not use up all of their allocated space. If the Reseller's maximum allowed disk space is exceeded by the sum of all of his/her Users (plus his/her own User account), an email and message will be sent to the server Admin(s) and to the Reseller notifying them that the Reseller has used up 100% (or more) of their allocated disk space. Nothing will be done by DirectAdmin, as the Reseller and Admin can work out a solution on their own, without having to suspend any User accounts. Bandwidth on the other hand, isn't so forgiving. If the maximum bandwidth allocated the Reseller is used up, the Reseller's account AND all of the User accounts under it will be suspended until either the maximum usage is increased and the Reseller account is manually unsuspended (or you can wait for DirectAdmin to unsuspend it during the daily tally, assuming an increase in the limit) OR a new month arrives and the Resellers usage will be reset to zero.
The User Panel is where all end-users will go to access their accounts to setup their web sites.
The FTP menu allows Users to create FTO accounts to access their website. There are many variation on how this is done depending on what type of account the User has. If the User owns his/her own IP address, the ftp.passwd file will be stored in their DirectAdmin config directory. If using a shared IP, all accounts are stored in the proftpd.passwd file located in the /etc directory. Users who own their IP will have the ability to create accounts that do not need their domain at the end of the ftp login name. For example, site with shared IP's require that the ftp login name contain @domain.com at the end: ftpuser@domain.com, whereas an owned IP will only require: ftpuser. This does not include the system username, where in either case, the @domain.com is not required. The 3 types of FTP paths (Domain, FTP and User) are defined as follows. Domain FTP accounts have a home directory in the root directory of the domain. This means that this account can access all aspects of the domain while not being able to see any other domains on the Users account (/home/username/domains/domain.com). The path "FTP" will have its root directory in the public_ftp directory of the domain (/home/username/domains/domain.com/public_ftp). The "User" type of FTP account will set the root directory of account to a directory located in this domains public_html folder which is named the same name as the account. For example a User FTP account named 'gary', will point to /home/username/domains/domain.com/public_html/gary. This allows for the creation of sub-users, if the system User wants to create a hosting site. This also matches up with subdomains, in that the subdomains will point to the same place: http://gary.domain.com points to /home/username/domains/domain.com/public_html/Gary.
The "Statistics / Logs" screen is used to provide a clear list of all details about the User'ss account. It will show all domains that the User has on this account, as well as stats about them, and links to their Webalizer stats. The main purpose is to show the total summary of all usages over the entire User account. This includes details on bandwidth usages (web, FTP, DirectAdmin) and disk usage (User accounts and databases). It's important to note that the stats reported on each domain are only there for the Users information and are not used for the total usage, as the total usage is a summary of all domains combined and other such things. The lone editable email account listed on that page does NOT currently have a role. It's purpose is to provide the e-mail account the User wishes to be contacted by... however, the e-mail provided with the message system is the one that will be used when system messages are sent. The bottom line is, the e-mail field on this screen is saved for future use.
The file manager is a very concentrated tool allowing the User to do many things to their account. The file manger main purpose is to show all files located in the User's home directory and to allow the User to make modifications to their locations and contents. The basic navigation should be straight forward to figure out, but some of the functions may require some explanation. Like all tables in DirectAdmin, the data is modified by first selecting it on the right using the checkboxes, and then pressing the desired button below. In this case, there are many buttons. The first button is called "set Permission". This button has the same function as the "chmod" command at a Unix command prompt. Beside it is a value called the mode. This mode is what determines who can do what to the file. Generally a mode of 755 is required for all web documents so that everyone can see them. To set the mode of the selected files, simply enter the desired mode in the field and click "set Permission". This will change all directories and files selected to that mode. The next 2 buttons, "Copy To" and "Move To" are similar in that they both utilize dropdown listbox beside them. The listbox is basically a very condensed version of the User's file system tree. Each colon ':' represents on level above the text on the right side of the listbox. The value of the colon can be seen by clicking the box to dropdown. Follow the colons upward to go one level one up from the currently select one. Although "Move" will move everything, including directories, "Copy" does not currently copy directories. It is planned to implement it in the near future. You can view any files by clicking their name, and because of the format of the command request, your web browser thinks that CMD_FILE_MANAGER is a directory, so you should be able to view all HTML and any file its linked to without any problems (not including scripts, and all links must be local, the cannot start with / for it to work). The "Edit" button to the right of the filename will allow the User to edit any files that they want (with in their home directory). The "Preview Html" button on the edit screen will take any HTML written in the text area and dynamically write it to a new window without saving it back to the server, so that you can view any changes without having to upload a possibly erroneous file. Files that are not shown with an edit button can be edited by manually typing in the command ("?action=edit" after the filename), but you do so at your own risk, as text areas aren't designed for editing binary files. You might notice a checkbox beside the "Create New File" area. All this does is insert some basic html code to speed up any website testing or creation that may be done. Users will not get a checkbox beside files owned by root. This will remove any confusion caused by Users who do not understand Unix file permissions and ownerships, as they wont be able to do anything to them (even though a root file in a User directory can be legally deleted).
"Install SSL Certificates" is only applicable to Users who own the IP that their site is using. This is because all https requests will be encrypted, and the "Host: domain.com" header will be encrypted too, so Apache will not know what virtual host to use. This is why IP's must be owned first. There are 3 main choices for the SSL screen. The first is to use the server's certificates. For basic SSL encryption this is fine, but a popup window will appear each time a web browser tries to view the secured page. The next method is to create your own certificate. There 2 methods for this. The first is to create your own self signed certificate. Although your personal data will show up in the cert, a popup will still get in the way of anybody trying to view your site. The 2nd creation technique is to create a certificate request (CSR). This is the first step to get a standard SSL certificate which will be authenticated by a certificate authority. After entering your information, you will get a new screen containing text. That is your certificate request or CSR. You will give the CSR to an authority of your choice, and then paste the certificate below the generated key in the text area on the main SSL page. This is the 3rd option for the SSL screen. In order to use the pasted key and certificate, they must be valid and contain the proper header and footer so that DirectAdmin can find them. If you use a certificate authority, you will need the CARootCertificate file to prevent the popup from showing up during browsing. Do this by following the link below the table and following the directions.
Users can host more than one domain on their account. By going to the "Host Additional Domains" screen, they can add more domain (if they are allowed). This screen can be deceiving because the maximum bandwidth may show 'unlimited', which only means that the domain is allowed to use up as much bandwidth as it can until the User's account limit is reached. The User can set this to a number if they wish to not have domain use more than a set amount (possibly useful when more than one domain is used). Its important to note that no matter what number is entered, it will always be capped by their User account.
The ticket system and the message system are essentially the same thing. The only difference is that tickets can be replied to and messages, not. Messages generally go from creators down, while tickets are created from Users or Reseller up. When creating a message or ticket, Admins and Resellers will have a listbox for them to chose who they wish to send the message to, while Users will only be able to send to whoever created them. Users can reply to their tickets before they are responded to, if they learn anything new. Only the person receiving the ticket can close it.
"Signing out" shouldn't be trusted. It's only a basic method using cookies to tell the browser to tell DirectAdmin that the next time it tries to access something, send "Login Failed", which will popup a username/password entry field cause the browser to forget the password. The only true way to log out is to simply close all instances of your browser. (also depends if you browser has the ability to save your username and passwords).
You can e-mail questions to sales@directadmin.com or send an inquiry by visiting the contacts page. We are available Monday through Friday, 9 AM - 5 PM Mountain Standard Time. You may also visit the forum to see if your question has been answered there.