[Server-devel] Web-based Management Interface for the XS

[John Gunkel]

On Mon, Mar 24, 2008 at 11:25 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> 2008/3/25 Aaron Huslage <huslage at gmail.com>:
>
> > This breaks a design goal actually. If you check out the Bitfrost pages
>  > (start at: http://wiki.laptop.org/go/Bitfrost) you'll see that centralized

I did. I wasn't suggesting to issue every child a cert, rather to use
it as a configuration store. The design goals also state that there
must be a centralized place for the child's data to be stored ("No
data loss") why not treat the child's "meta" information the same way?
So,other than the "limited institutional PKI" (Which again, I was not
advocating here) I would be interested to know what part of the goals
you see keeping the configs and user info in a database that is
specifically designed for that task violates the goals stated on that
page.

Even puppet (suggested above, and which lacks a web interface) works
with LDAP. You could conceivably put the lego together like this to
admin the XS:

FDS web interface -> LDAP -> puppet

where the services that supported LDAP directly would use it directly.
Then puppet could peel out the rest of the configs for bootstrapping
other services or for those that don't use LDAP. We would still need
to have another small web interface to do some house keeping tasks
(shutdown, adding disks, etc.) but that could then be lifted from
something like freenas.

Swap the LDAP block for any other database, likewise with the web
interface, and it would still hold true.

>  > stuff is pretty discouraged in the spec, and that would cover the LDAP idea
>  > I think. Additionally LDAP is flaky in a sporadically connected environment.

Ah! I should probably also mention, that I wasn't talking about having
each XS replicate to eachother, (although, now that you mentioned it,
that would be a feature for bigger environments) but rather that a
given XS would have it's own LDAP store for information. Now I
understand your objection.

>  > I don't think putting an LDAP server on the XS is a good idea, to be honest.
>
>  Exactly. LDAP has lots of problems. It was great as a common way of
>  interoperating in early days, where you couldn't get your MTAs, OSs,
>  applications, etc to all talk to all (closed) databases. These days
>  everything talks to libpq (PostgreSQL) and libmysql with no problem,
>  and the relational model scales much better.

Good point, I forgot about the PostgreSQL database onboard.I just hate
to see people reinvent the wheel when it comes to stuff like this,
especially when the management part of this (gui/web) has already been
built.

But, if the design/architect guys (I seem to remember seeing an
announcement a while ago) have determined that the best way to go is
to use a database backend, then so be it. It especially make sense if
it is being used for other services offered on the system.

In which case, to maintain consistancy, a web front end could be used
to stuff the database, and puppet (cfengine/whatever you want) can be
used to pull everything out. Postgres recovers _fairly_ gracefully
from having the power yanked out from under it, (as long as you have
your transactions set up properly,) so as long as the database comes
up nice, puppet could regenerate everything else on boot.

What's left then is stuffing the database...

>  The only thing that LDAP has of different and perhaps interesting is
>  the deletated/distributed model, but as noone uses it, it hasn't
>  matured either :-(
>
>  Let's avoid that tar-pit ;-)
Definitely. I'll leave the discussion about LDAP's merits and
deficiencies for when there is more time to burn :-)

And as for access to the admin interface directly from the WAN? My
vote would be no. Through an SSH tunnel? Sure, but directly over the
web would be a bad idea, I think.