[CentOS-devel] NethServer as CentOS Variant and SME SIG Proposal

Sat Jan 11 21:11:51 UTC 2014
Les Mikesell <lesmikesell at gmail.com>

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.   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.

 > 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.
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.      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.

   Les Mikesell
      lesmikesell at gmail.com