I just don't have time to even think of adding Deployment Guide to the list
Perhaps I'll make my own top secret Deployment Guide. This is an RFC for you to correct the errors in my logic. That other stuff you're working on only fills about 8 hours of your day. I'm here to help you fill the other 16.
Why should I add DirectAdmin to my control panel choices?
Add reasons here.
DirectAdmin Design Concepts:
1. DirectAdmin by design is not a clustering control panel. Some control panels use the word cluster, only to mean DNS services, which doesn’t require a control panel to manage. The flexibility, reliability, and performance of DirectAdmin is due in part to its lack of dependencies and required communications with other servers. It’s also a compiled C program rather than an interpreted language. Unlike true clustering and grid systems where servers must have very restricted configurations, DirectAdmin allows tweaking of the server services without breaking the system. There are inexpensive products available that leverage the DirectAdmin API to automate provisioning and billing without introducing complexity and single points of failure for the control panel and other services for all users on all servers as can be the case with clusters.
2. DirectAdmin, users, resellers, and admins, are each recognized by the operating system as a user. The elevated access and visibility of resellers and admins are implemented by DirectAdmin independent of the operating system. When admins and resellers work in user areas under their control, they use the credentials of that user which avoids creating ownership issues. Also, any granularity below the operating system user, such as domains, sub domains, databases, e-mail users, ftp users, etc., are also implemented by DirectAdmin independent of the operating system.
3. The DirectAdmin hierarchy is such that each user must belong to a reseller and a reseller must belong to an admin. Looking at it from the other direction, an admin has reseller, and user properties. A reseller has reseller and user properties, and a user has only user properties. Thus you could have an admin whose reseller attribute allows him to have users, and whose user account allows him to have domains of its own. A reseller would be similar in that it could have users and its own domains, but it would need to belong to an admin. A user must belong to a reseller.
Users, Resellers, and Admins
1. User level: Where the user will have multiple domains, you should not locate any domain under that user that have the potential of needing to be moved to a different user because some elements of the domain are prefixed with the user name. This is necessary so that users can have databases with the same names etc. The user1_ dbase wouldn’t be visible by user2_ after a move/restore of a domain to another user. DirectAdmin has command line tools to move domains between users on the same server, but databases etc. would need to be recreated by hand, and the dump file edited to reflect the new user prefix. User level backups are the most portable since they can be restored to any reseller. The one restriction that applies in all cases is the user must be unique to the server, or it belongs to the same reseller on the new server and the intention is to overwrite.
2. Reseller level: Even if you don’t use hosting resellers, the DiectAdmin reseller user is still an effective tool to group users for management and backup purposes. The reseller backup can backup the reseller user, users assigned to the reseller, and all of their domains. The important difference between this and the sum of user level backups is you are also picking up the reseller unique information. Resellers, who are not also admins, can have their backups restored to any admin on any server provided there are no user name conflicts
3. Admin level: Admin is a way to group and manage resellers. The admin backup can backup the reseller users, users assigned to the reseller, and all of their domains. The important difference between this and the sum of user level backups is you are also picking up the admin unique information. Admins who are not also the default admin user, admin, can have their backups restored to any server provided there are no user name conflicts. However, there will be a conflict if you use the default admin user, admin because it is the initial admin account named admin that is made by the DirectAdmin install script.
Strategies:
1. Perhaps creating a domain at the default admin’s user level to provide a basis for the name server on the server that isn’t used for real traffic makes sense since it plays to the DNS automation inherent to DirectAdmin. Because of the portability implications mentioned earlier, it’s difficult to envision a scenario where it would make sense for the default admin at the user level to have more than one domain. If you have few domains and no good reason to want to group them, you could make use the reseller capabilities of the default admin. Restores or moves to another server would need to be done with user-level backups, moving users one at a time. Of course a single user can have multiple domains. What is clear is using the default admin account places certain restrictions on you with regard to portability, backups, and restores.
2. You could create a non-admin reseller under the default admin, and group users and domains under that. You could then easily move the reseller and users to another server as long as the reseller and all users are unique users on that server.
3. You could create another uniquely named admin level user, and assign resellers and users it. This would allow you to easily transfer and entire group of resellers and users to another server. An example of where this may be useful is consolidating servers. If you had a server with an admin named mars, and another with an admin named venus, you could move both to the same server as long as there were no user name conflicts. Neither would conflict with the default admin user, admin.
DirectAdmin installation script explanation of choices and implications:
Pre-installation checklist: