RFC: Centrilized managment console

[Nicolas Valcarcel]

Dan: that's the exact contribution i was expecting :D

The most tricky part is to define a structure of meta data for this (i'm
thinking in metadata as the one defined in ufw's specification [1] a sort of
plain text format or xml file to use it as part of the parser (maybe use a
"dynamic" parser that defines his parameter with those files) but i'm kind
of stuck on that, i'm out of ideas for now and we will reach the bluprint
freeze tomorrow, so i need some help on this.

1.
https://wiki.ubuntu.com/UbuntuFirewall#head-420cfccabaafd264947d8b97cfa03926089a07e7

On Wed, Jun 4, 2008 at 6:24 AM, Dan Shearer <dan at shearer.org> wrote:

> On Tue, Jun 03, 2008 at 08:00:31PM -0500, Nicolas Valcarcel wrote:
> > I have been working on the blueprint of a centralized managment console
>    :
> >
> https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-centralized-services-administrator
>
> I'm not sure how best to contribute, so I'll start with a few comments
> here first.
>
> Rationale
> ---------
>
> I wonder if the Rationale section is maybe looking at the right things
> from the wrong starting point.  To me the deeper analysis is:
>
>    Ubuntu Server has no awareness of itself as a product.
>
> Yast, webmin and the rest don't address this either.  Personally I'd be
> delighted to stick with existing Ubuntu Server tools for managing
> services (thanks, Debian, upstreams!) and just overlay a higher order of
> understanding and control. Which, at our later option, we can make as
> GUI as we like, or as is required.
>
> There's a subtle point here that was only hinted at before, I can't
> remember who made it. The good thing a lot of us see in the Microsoft
> admin tools is that they have this higher order of understanding to some
> degree. Not so much just that there is a GUI. And that is where I think
> some of the debate on this list has been like ships passing in the
> night, people not realising that the others are talking about different
> things. I despite a mandatory GUI as much as the next Unix person. But I
> recognise value in a network-centric management view, such as delivered
> nicely by some GUI tools.
>
> Outline Sketch Implementation
> -----------------------------
>
> Following is a sketch of a commandline tool ubuntu-server-admin.py that,
> if it existed, would give me confidence that a useful admin tool could
> be built on top of it. My tool would be interacting with existing Linux
> and Debian management facilities, and would use a database. I have a
> clear idea for how the database would work but that's detail.
>
> u-s-admin --report --overview returns an XML summary file that says:
>   name = X, otherwise known as Z
>   services I'm running that matter to users are A,B,C
>   the locations of my vital data are D, E, F
>   the network services I depend on are G, H I
>   the network servers I depend on are J, K, L
>   the machines to which I log messages are M and N
>   the machines monitoring me are O and P
>
> (where I say 'machine' above it is likely 'CNAME' in reality to avoid
> hard coding)
>
> u-s-admin --report --depend-network-services would return:
>   DNS server details, and their current status
>   KDC server details and status
>    :
>
> u-s-admin --report --depend-network-servers would return:
>   Server J: rsync for backup, on port X; and current status
>   Server K: SQL server for webapp we're running; and current status
>   Server L: web proxy for accellerator for Apache we're running; and
> current status
>
> Given this level of awareness, next we need to configure these things.
> The fact of this configuration would not be kept in the database, the
> database would only be for the higher-level understanding. This would be
> making calls to debconf or apachectl or whatever makes sense, and these
> tools just manage state the same way they always did.
>
> --
> Dan Shearer
> dan at shearer.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20080604/b6ba4551/attachment.html>