Dan: that's the exact contribution i was expecting :D <br><br>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.<br>
<br>1. <a href="https://wiki.ubuntu.com/UbuntuFirewall#head-420cfccabaafd264947d8b97cfa03926089a07e7" target="_blank">https://wiki.ubuntu.com/UbuntuFirewall#head-420cfccabaafd264947d8b97cfa03926089a07e7</a><br><br><div class="gmail_quote">
On Wed, Jun 4, 2008 at 6:24 AM, Dan Shearer <<a href="mailto:dan@shearer.org">dan@shearer.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Tue, Jun 03, 2008 at 08:00:31PM -0500, Nicolas Valcarcel wrote:<br>
> I have been working on the blueprint of a centralized managment console<br>
</div>   :<br>
<div class="Ih2E3d">> <a href="https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-centralized-services-administrator" target="_blank">https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-centralized-services-administrator</a><br>

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