Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Feb 1998 20:26:29 -0800 (PST)
From:      Alex Belits <abelits@phobos.illtel.denver.co.us>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com
Subject:   Re: WebAdmin
Message-ID:  <Pine.LNX.3.96.980203154555.29185C-100000@phobos.illtel.denver.co.us>
In-Reply-To: <199802032255.PAA01679@usr01.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Feb 1998, Terry Lambert wrote:

> > > is answered there, in great, gory detail.
> > 
> >   *between* them -- in the case when remote administration is done not
> > through LDAP, and authentication comes through something else. If only
> > local sockets are used, there will be no need for further authentication,
> > however it creates two possible places where authentication will be
> > possible to perform -- before or in LDAP, and depending on the protocol
> > used it will be in one of those places.
> 
> Yes.  As stated, the RFC's describe an "AUTH" mechanism.  If you
> need more than that, then use NDS or X.500, with an LDAP server
> operating against the MIB.

  Is your idea to transfer authentication information "transparently"
from "wire protocol" or authenticate over "wire protocol", check access 
and use separate authentication information for LDAP?

[skipped]

> > that. Database-like backend (but not necessarily replacing all config
> > files with one big database -- one can handle files as database while not 
> > keeping it in any permanent storage) makes sense, but what is the
> > reason for dragging in the protocol with it.
> 
> 1)	Schemas are transportable; database files are not.  Using
> 	the protocol abstracts the schema from the implementation.

  Tab-separated lists are very portable. URL-encoded lists are even more
portable -- they have predefined encoding rule for "odd" characters. In
any case configuration replication can't be done between host that
supports configuration database-like system and one that doesn't, whatever 
database-like system is chosen. It's good to use a protocol that everyone
can understand and build such system over it, but portability is hardly
the unique feature of LDAP.

> 2)	Everyone will eventually support LDAP.  Sun does.  Netscape
> 	does.  Novell does.

Sun doesn't configure their hosts by LDAP (and considering their
creativity in protocols, unlikely will). Novell doesn't and even less
likely will. Netscape will only if every system its server runs on, will.
All protocols except some irrelevant to this discussiuon proprietary ones,
are implemented everywhere, and none of them are used for remote
administration system of this kind, especially portable one.

> 3)	There is already a reference implementation.  What you are
> 	proposing does not have one.

  Managing lists taken from url-encoded form input has more
implementations than necessary, interfaces to databases exist, too
(probably LDAP-like ones, too), and I'm not aware of any
existing implementation of FreeBSD tadministration hrough databases or
LDAP.

> 4)	It is already a standard.  What you are proposing is not.

  Both protocols are standard and both require something to be placed over
them to achieve the stated goal. Also it's obvious that the administration
framework that should be placed over any of those protocols to become a
base for remote administration system. I propose something of the same
scale over HTTP that your propose to make over LDAP, and I prefer HTTP
only because its requests structure and expected actions seem to be closer
to the expected from the whole system's model.

> 
> > > > Or there can't be any propagation or host-dependent macros, and
> > > > everything must either have only one administrative server or be
> > > > managed in the boundaries of one host?
> > > 
> > > LDAP supports referrals.  Read the RFC's.
> > 
> >   I am talking about operations, not just storage. For example: "Change
> > default nameserver to the local nameserver on your subnet if it exists,
> > otherwise to 192.168.111.222" -- and decision what to say to actual boxes
> > is left to the local administration server.
> 
> This is too complicated.  How would you present this as a radio button
> list, a checkbox, or an input field in a user interface?  If the
> answe is "you can't", then the model is too complicated for users to
> understand.

  IMHO the system shouldn't be made in a way, "only every fool can use it"
-- if you propose heavy modification of the configuration data storage you
can't make new system less flexible than original one. I can make a script
that will perform this on the files, rsync hundreds of hosts with it and
make cron run, then delete it. Ugly, requires writing separate files
editing procedure for any kind of configuration, but very efficient. If
the system will have "nice" remote configuration editing capability, I
expect the same thing nice way, too -- if someone can't make script in it,
distribute and call it "by one button", it's his problem, but one who
needs it deserves to have it.

> How many people do you know who know how to work lamps?  A computer
> should be as easy to operate as a lamp or a television.  A VCR at
> worst case...

  Whth predefined operations of this kind it may pass for
"configuration wizards" system ;-)
 
> > > Ideally, monitors will fade away to nothing, as intelligent programmers
> > > rewrite these bad programs to make them stat their configuration data
> > > files occasionally before running (worst case) or to directly use the
> > > directory themselves (best case).
> > 
> >   While running, not on startup. You will have to make those programs
> > aware of monitors and be capable of reporting success or failure of such
> > reconfiguration -- and something should react to failures and recover
> > systems while still supporting transactions. Programs that report failure
> > won't be able to do much because their reconfiguration is a part of
> > transaction, and they only can tell that something is wrong and hope that
> > one who started it will return system into usable state. IMHO it's way
> > more complex than just providing atomic updates in simple situations.
> 
> I think it is wrong to cause the smtpd (for example) to enforce smtp
> configuration semantics.  The enforcement must occur before the change
> takes (a "schema-check").

  They already enforce it. I change configuration, program returns an
error. Trying to make all possible chacks before the program, then giving
configuration to it blindly, ignoring program's errors produces very
fragile system.

> [ ...more "HTML as a replacement for SQL" ... ]

More like limited frontend to it -- some complex lookup can be done in
completely different way (say, LDAP).
 
> When the only tool you have is an HTTP server, everything looks like a URL.
> 8-).

  Not really, just IMHO HTTP semantics is close to it than LDAP one -- no
one originally expected LDAP to perform some complex actions on complex
system with parts that can succeed or fail. HTTP more or less was supposed
to have something "do things" on request.

> > > You could use a "client poll" based mechanism, but the delay you
> > > will introduce doing that is, IMO, unacceptable for a batch create
> > > of 200 users at the beginning of a Semester/Quarter.
> > 
> >   Why? Adding a user or a set of users is a single transaction. Who is
> > the client and who is the server in your example?
> 
> The "client" is the "adduser" command line utility.  The "server" is
> whatever actually ends up adding users.

Then who has problems with polling? Transaction won't end until data is
received back.

> > > You could use "multipart/replace", but that would seriously limit
> > > the available clients.  What is needed is a "server push" technique
> > > that is not delay-loop polling, and is supported across all servers.
> > > LDAP offers that, HTTP does not.
> > 
> >   Why? Server produces responses to requests while requests and
> > responses pairs represent transactions. There is nothing for server to
> > tell to the client after the transaction is done, and client can initiate
> > transactions whenever it needs to.
> 
> Because !$%@*! Netscape and MS-IE timeout if their idea of "fast enough"
> is not met by the server.  You are faced with server push, or you are
> faced with polling using "GET", or some silly "send comments" keepalive.

  Then don't use them for sending the requests for transactions that take
20 minutes to complete. Protocol has absolutely nothing about enforcing
response time limits, and for [incompatible] HTTP clients that do it one
can build a simple proxy that will fix it by whatever means including
polling. I am talking about a protocol, not GUI clients for it (LDAP has
nothing better suitable for being an interactive client for this system
either).

> >   Monitoring the status and changes not initiated by the client is
> > different task, and most likely it won't be an HTTP browser that will do
> > it -- and for custom client any kind of "envelope" of update message,
> > including MIME multipart, can be used.
> 
> Ugh.  Writing a parser for all this would pretty much suck.  There are
> good reasons these programs are compartively huge.

  Parsing HTTP (MIME) is very simple and parsing valid HTML (SGML) is
more complex, but again, noninteractive things won't need HTML --
operating on lists requires only parsing lists themselves (in my skipped
example it was URL-encoded list), and parser for that is exremely
primitive. Generating HTML form of lists for interactive use, again, is
simple.

  Implementing all possible monstrosities of multi-file HTML with
frames and layers, scripts and style sheets over HTML, layout with table
cells that should self-adjust its size for elements inside that also
change the layout depending on boundaries defined by that cell, etc. is
something that makes certain HTTP clients that large.

> >   The whole thing can be implemented through HTTP without any browser
> > involved -- it's just nice to have interface that can be used from it
> > directly.
> 
> That's the rationale behind LDAP.  I can ownload a client from UMICH
> right now.

  The same for all kinds of HTTP clients including libraries, command-line
HTTP request utilities, etc. IMHO choice of protocol should be based on
something where they differ more than that.

> >   Configuration update doesn't need any server push -- client always
> > initiates the transaction, and there is only one result returned to it.
> > Server-push can be used for monitoring, but it's hardly an important
> > part of design.
> 
> How do you replicate this information to a Sun or NetWare or NT box,
> without rewriting the code for Sun or NetWare or NT?

  I can't with any of those systems -- Sun, Netware and NT has no
HTTP or LDAP remote administration implemented. If any of both
configuration systems will be portable, it may be possible, however I
don't believe that copying Windows registry to Solaris box will do it much
good.

> >   HTTP multipart/replace server push is made without breaking
> > MIME, so it at least fits into the protocol, however in this case it's
> > unimportant. 
> 
> Apache times out CGI's that "take too long".  How would you deal with
> this problem?  Not use Apache?  Then what?

  Apache has modules, and I never said that I consider CGI to be suitable
for this task. Apache modules IMHO aren't the best choice for that either,
and I wrote my own HTTP server just because I wanted to make something
that won't impose request procesing model and processes/threads/resource
management system, used for the server itself on every program that can be
called from it. That server is at least one thing that can handle HTTP in
a way suitable for remote administration -- and probably there are others.

--
Alex




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980203154555.29185C-100000>