Multiple Actions Required to Add Domain
When I go to the Sites module in the User or Admin interface and add a new website, this does not appear to be sufficient to have the domain actually work. So, it seems there are several steps that I must take to install a single domain:
1. Sites > Add new website OR
2. DNS > Add new DNS Zone with Wizard
3. Email > Add new Domain
4. Email > Email Alias > Add new Email alias > ADD postmaster, abuse, etc.
And maybe I'm missing some items. Do I understand correctly that I need to do these things semi-manually whenever I create a domain or subdomain?
Is there any way to do all of the common activities that I'd do when I or a customer adds a new domain or subdomain?
Subscribed to HowtoForge
I've subscribed to HowtoForge and have downloaded the manual. It's for Debian instead of CentOS, but I'm hoping that it will provide some of the answers I'm looking for about how ISPConfig might be able to do the common things that a person (or customer) might want to do without having to do them manually.
Some additional items:
1. Does ISPConfig have an architecture that I can add custom plugins that show up in the UI as additional capabilities? If so, I can write code to enhance ISPConfig to do these things.
2. Does ISPConfig have command-line APIs or REST APIs so that I can write headless scripts to do common operations?
1) yes. Ispconfig has server side plugins as well as interace plugins and addins fot the tools module.
2) yes. See remote api documentation and examples in the ispconfig 3 tar.gz file.
Btw. The manual is for all linux distributions and not just debian. Ispconfig works the same on every linux distribution. The manual just contains some additional parts for debian.
Thanks Till and Falko for your replies.
Some history: I've been using Kloxo for over a year. It has a control panel that looks like Cpanel and has a lot of functionality behind it. It looked very promising and provided a turn-key solution for hosting administrators.
Kloxo's big problem is that it is not keeping up with the releases of CentOS. It has issues with x64 and it can only work on CentOS 5.x. Also, it uses Qmail, an MTA that is no longer maintained. It requires that a person use their version of php (lxphp.exe - no, it's not Windows, it just ends in .exe). And, updates must come via their yum repository instead of standard repositories. Things like this can make it difficult for the Linux administrator to do important updates to match customer requirements or to take care of security considerations. Lastly, their code is presently unstable and people have had issues when taking the most recent updates.
Their team is small, but dedicated and hardworking. But, despite this, I can no longer wait for them to deliver a stable solution on today's CentOS that my customers can live with.
So, I started looking at the various options available. I eventually got the list of choices down to DirectAdmin vs. ISPConfig:
DirectAdmin - The DirectAdmin solution looks very nice and is a more turn-key solution than ISPConfig and the price is reasonable; however, it is a closed-source commercial package written in C++. It does have script and API hooks and customizable templates for a lot of flexibility. However, being closed source is a problem for us. If they were to offer their source code under NDA (see our forum post with them), I think they would be a more viable option. We have decided to offer this control panel to our customers with the caveat that we will be limited in the customizations that we can offer to our clients.
ISPConfig - The ISPConfig solution has a clean-looking interface, and while it does not provide a turn-key or perhaps as simple a solution for server management as some other control panels, it does provide what appears to be acceptably-complete functionality, extensibility, open source, and a vibrant user community. At this point, I have talked with our team and we have committed to offering ISPConfig to our customers as a choice of control panel and are now going to try to learn the best practices for customizing ISPConfig.
We're in the managed-server hosting business, so we want to standardize on a few control panels that we'd manage for customers. With the above commitment to ISPConfig now having been made, we'll next look to joining development efforts so that we can learn more of the internals of ISPConfig and also to be able to feed back to the ISPConfig community any fixes or features that might be acceptable.
Would you please point me to how to join the development effort so that we can begin this journey with you? Ah, found this: How to start developing ISPConfig!
Many thanks for everything you provide!
|All times are GMT +2. The time now is 23:06.|
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.