Les, Thank you for your thoughtful and though provoking comments. On Sat, Jan 11, 2014 at 2:11 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > On Sat, Jan 11, 2014 at 2:29 PM, David Loper <dloper at clearcenter.com> > wrote: > > I disagree. Perhaps that is because I see how these systems get used in > > actual production environments. While it is true that we don't touch upon > > subjects like 'racks of servers' as the typical use-case is doesn't mean > > that it isn't done on ClearOS, SME, NethServer and other similar boxes. > For > > example, I can set up 10 ClearOS servers at multiple locations with > > integrated directory services, PDC/BDC operations throughout and > > site-to-site VPN tunnels at to different locations all with relative > ease. > > My point is that the scope of knowledge and operations techniques is > very different (which is the whole point for these variations to > exist). For example, a typical enterprise level server manager would > know the names of the applications and the format of the configuration > files that would have to be modified to add a DNS name for a device > and have the matching IP assigned by DHCP, where one of these > appliance-like systems would just present a form with a few fields so > the user doesn't need to know that multiple services are being > configured, or even which applications are doing it. So let's write the module to do exactly what you need. The framework is designed to move up market. The ClearCenter Marketplace is a pluggable framework that allows developers to create solutions to the scenario that you list above while at the same time leveraging common information sets. It's more than a webpage that changes a config file and restarts a server. It's a framework that is tied onto the under-pinings of the OS. For the example listed above, you don't have to write the DHCP piece because the DHCP API object already addresses the allocation of that data. > Similarly, if > you want a user put into both an email group and a unix permission > group (or file/web server access group), a 'real' server manager would > need to know all about multiple applications where a good appliance > would hide all the cruft behind a single form. > > > While this isn't racks of servers, it does require, and these solutions > do > > provide, standardized deployment scenarios for Server Management. For me, > > server management has less to do with 'intimate knowledge' of a thing and > > more to do with 'ease of use' in deployment, reporting, and day-to-day > > tasks. That is what ClearOS, SME, and NethServer do, we are all about > making > > it very, very easy to use and very easy to manage. > > Agreed, but you replace the concepts of server management with your > own, hence my view that the user base would not overlap much. > I don't see why it couldn't also do what you want as well. Like all things Linux, it depends on how you use it. The purpose of the management interface of ClearOS is to rapidly accomplish best practices under a particular scenario. "We have an app for that" and if we don't, we can write it. An enterprise using Samba server for file services will use the same Samba on ClearOS as they will on CentOS. It's all the same. The difference is that they will populate 3-4 fields, for example, and the management app for samba will take care of the setting up the directory as a replicate, joining it to the domain, adding the server to the domain and running all of the validation. What was a 15 minute process is now reduced to mere seconds. Same thing goes for a Samba join to active directory, an OpenVPN configuration, or whatever. If there isn't a particular 'enterprise' function in our interface it is because it hasn't been written yet, not because it couldn't be written to accomplish it. Moreover, if you want to muck about in the smb.conf file after the fact and put some custom things in there, that's ok too. For the most part, we will not only leave your stuff alone, but we will show it in the UI if there is already a control for it. And if there isn't a control for it, let's put it in. > > > You do raise an important point about the aspects of our systems that is > > lacking and that is in the multi-server management space. Instead of > calling > > that 'Server Management' (which to me means the management or > manageability > > of a server) I call it 'Rapid Deployment and Automation'. Managing > multiple > > servers through an intimate knowledge of Linux voodoo falls in this > > category. Here we can turn to Puppet, Saltstack, Kickstart and others. > Many > > of these solutions and vendors don't consider themselves "Server > Management" > > but rather 'Automation.' We'd love to be able to ALSO integrate these > > functions within our environment. Hopefully, working together in this SIG > > space, we can come up with some standards and best practices to benefit > us > > all in greater adoption of these tools. > > Yes! - I'd really, really love to see the 'fill in the form' server > management systems converge with scalable configuration management > tools as a middle layer instead of directly mucking with their own > template schemes and local config files in their own weird ways. > Me too, we have a plan this how this gets accomplished. > That way the logical task-oriented operations control could map out to > a cloud of servers just as easily as one little box (or a home > firewall/file server/media player on separate devices). Salt and > ansible look promising in that space, with salt being perhaps more > scalable, responsive and portable. We are already in talks with salt. They are in our neck of the woods and we hope to work more closely with them on integration. > But, at this point I think it > is a big stretch to even consider that kind of convergence so I'll > stand by the statement that appliance-like servers that hide the real > management operations are a separate thing that deserve their own > separate group. > Yeah, make a group for that. We'll join it too. But server management is the space we are moving to and our development target. So all your ideas here are extremely helpful and welcome. Thank you. > > -- > Les Mikesell > lesmikesell at gmail.com > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140112/6e58c06d/attachment-0007.html>