Date: Tue, 3 Feb 1998 22:55:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: abelits@phobos.illtel.denver.co.us Cc: tlambert@primenet.com, 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: <199802032255.PAA01679@usr01.primenet.com> In-Reply-To: <Pine.LNX.3.96.980202201628.25875A-100000@phobos.illtel.denver.co.us> from "Alex Belits" at Feb 3, 98 09:42:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Looks like AIX. More like NT' or NetWare, actually. AIX has a lot of seperate, incompatibly formatted files. Both AIX and NeXTStep's niload/nidump also maintain two copies of the data, which must be soft-synchronized (ie: read as "dumb"). > > > and if in two places, how authentication information and/or credentials > > > will be passed in this system between them? > > > > Read the RFC's. LDAP is an IETF standards track protocol. The question > > 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. The good thing about LDAP is that it is implementation neutral, like this, unlike some private protocol that you won't see running on a Sun system. There are already LDIF's (IETF drafts on the standards track, themselves) for POSIX MIB's... but without transationing in the protocol, they must be revamped in terms of container objects. > > If a change needs to be propagated within an administrative Realm, > > Yes, "LDAP will do that". > > > > If you are talking about the atomicity of the contents of a POST'ed > > form specifying new data, the atomicity must be handled by correct > > form design. The httpd exposing the LDAP objects must account for > > the objects at the container level. Which it can do, easily, with > > the given container design for transactioning. > > The only question is why. LDAP in this situation acts as an API to > database encapsulated into protocol, but if protocol is used only locally, > what is the point? Why not to manage bare database -- not that LDAP > provides exactly the functionality we need. If the intention is to use > LDAP as the only protocol for network propagation of changes, etc., I > don't understand the reason for it -- with the need for external > transactions support it doesn't look like the best psooible protocol for > 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. 2) Everyone will eventually support LDAP. Sun does. Netscape does. Novell does. 3) There is already a reference implementation. What you are proposing does not have one. 4) It is already a standard. What you are proposing is not. > > > 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. 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... > > 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"). [ ...more "HTML as a replacement for SQL" ... ] When the only tool you have is an HTTP server, everything looks like a URL. 8-). > > 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. > > 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. > 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. > 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. > 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? > 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? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802032255.PAA01679>