On Mon, 13 Jan 2003, Evgeny Stambulchik wrote:
> >>>And anyway, I remind you that there is already a remote access protocol on
> >>>linux that is quite powerful, and works very well. It also fits into the
> >>>unix framework: rsh/ssh
> >>
> >>Fantastic. Ever wondered why people invented HTTP? Of course, these were
> >>Windows freaks who didn't know how to use telnet. The "unix framework"
> >>would be to ssh to the web server and run the browser there. Right?
Actually, they had an ugly "browser" called www. And in 1989 there weren't
too many MS-Windows freaks around.
At that time there was already something called gopher.
> >
> >
> > Hey: I specifically excluded telnet!
>
> What's the principal difference here, for the heaven's sake?
(forgot a ;-) )
>
> > Anyway, http is a simplified ftp, not a simplified rsh.
>
> Exactly. So you answered yourself. When there is a remote data (HTML files
> in the case of WWW) there are two ways for a user to access the data: 1)
> login to the remote computer and run an application (web browser) there
> and somehow display the application's interface back or 2) retrieve the
> data to the local system and run the app locally (and send the modified
> data back, if required, using the same protocol that was used for fetching
> it). The second approach is called "the client-server model". Shall I go
> in depth proving that 2) is superior?
No. The thing is that I don't need to give anyone on my net a full shell
access to that web server. Also: following links is just not the same if
you have totype your password over-and-over again.
>
> > I actually access my imap account via ssh to the mail server ('ssh
> > mailserver /path/to/imapd') ...
>
> No. What you're doing is tunneling the IMAP protocol via the ssh tty
> session. Why you're doing so is quite beyond my understanding, though (a
> firewall blocking the IMAP port? - but why not usual port forwarding that
> ssh is so good at?).
To use ssh public-key authentication, of course. wu-imap, when run
locally, is automatically past the authentication phase
> At the other end of the ssh pipe an IMAP-capable mail
> reader is listening anyway.
>
> >>If rsh/ssh is the ultimate answer to the
> >>remote management, then vi is the ultimate configuration GUI. Not?
> >
> >
> > You seem to confuse "usage" and administration" in the above examples.
>
> No, it's you fail to realize that "administration" is a form of "usage".
> For a web browser application the data is HTML files. For a management
> console, the data is config info.
I realize that, but...
>
> > It is a powerful remote administration tool that you should not break.
>
> ??
The fact is that I can run my systems remotely. ssh access to a machine is
enough to do almost any administration task. I can also easily write
scripts to do whatever needs automating.
>
> > There is one thing you should keep in mind: GUI can't be automated.
>
> Why did you jump at GUI? Whether I'm using Mozilla to browse the Net or
> downloading a Mandrake ISO with wget the HTTP protocol comes handy. And
> both Mozilla and wget could potentially use the same HTTP access API if
> such a thing existed on all flavours of OS the two applications are
> running. Same about IMAP: KMail (GUI) and fetchmail (GUI-less) both use it
> instead of logging to the remote server via ssh. Same about config.
>
> > An API, as nice as it is, still takes some effort to automate.
>
> Come on. The point is _unification_. If a device has ten screws, nobody
> would deny it's more complex to deal with than a single one. But if each
> of them is different in size/form... Yes, that's the current state of
> affairs in the Unix world of configuration. A nice car with hundreds of
> screws of different types. You have to learn how to use a few dozens of
> different screwdrivers. For a few large polished screws you can buy an
> electric screwdriver; however, 1) the electric tool, albeit fast, is very
> rough and 2) once you started using the advanced tool, an attempt to
> tighten one of the polished screws with a usual screwdriver risks the car
> stop working. Imagined?
>
> > If you want something done via cron: you need a shell command.
>
> Sorry, I lost you here completely. What did you try to say?
>
> > Another thing to keep in mind: current package management tools are built
> > around files. A file cannot be part of two packages. Config files fit very
> > nicely into this scheme: there is a clear definition who is responsible
> > for each config file.
>
> The "clear" definition appears very dirty at a closer look. Ever tried
> changing hostname of a multi-protocol server? The hostname pops up in a
> dozen of different config files. Which package is responsible for
> hostname? Plus, it should be changed on all clients accessing the server
> and possibly in the firewall configuration.
>
> > If more than one package should change a certain
> > config file, then the package
>
> Which of the two (or more)?
>
> > providing this file must provide the
> > (command-line) API to edit this file safely.
>
> There would be no need for the primitive tools like vipw if the config API
> took care of the locking/concurrent access issues. And it is much easier
> and more reliable in C than dumb locking that vipw uses.
>
> > This modularity is another thing that has to be maintained. One thing that
> > has to be done in any such configuration scheme is to define "domains"
> > whose are in the responsibility of certain packages.
>
> Is it impossible?
>
> > Another point: you mentioned cups as a good example of a package with a
> > clear configuration API
>
> No, I mentioned CUPS as a good example of the printing subsystem with a
> clear printing API. Other printing systems (BSD lpr,...) don't provide API
> at all. Results: enabling printing for a third-party application using
> CUPS is a snap from the programming point of view.
The programs provided the API that was originally needed: |lpr
Works well, assuming the system has a default printer configured (which
should be the standard, anyway).
Anyway, give pdq a try. (the only print system that does not require
root!)
>
> > But if you design a generic config API, you simply don't have the right
> > "actions" or "verbs" in advance:
>
> I don't need them. An XML editor can parse and load _any_ XML dialect, be
> it XHTML or SVG. And if you know what're you doing you can make any
> changes you want, including those breaking the specific format (but not
> XML as such). But if, in addition, you provide a respective DTD, the
> editor will become really smart - like colorizing the text, putting icons,
> providing help tips etc. So, each application can provide its own config
> schema. I suggest you read the GConf docs
> (http://www.gnome.org/projects/gconf/).
Interesting. But this only defines what is a valid syntax, and does not
define how to transform one valid syntax to another. The smart
configurator can tell you if you have made an error in configuration, but
it really does not allow any "action": if any configuration requires some
synchronization between two config keys, then the editor can't easily know
about that.
You can have the application put call-backs there to syncronize
those two keys, but that can create a number of unexpected effects and
strange effects (not to mention the extra resources taken)
Also: xml still doesn't allow me to easily:
*font: fixed
This is because XML assumes a tree structure, and this wildcar below
applies toall leaves wirt the name "font". So you see: a tree schema
doesn't always work...
And I still don't l;ike the current gconf: it requires an extra daemon
(Not a matter of resource waste, but a matter of complexity: see their FAQ
question "why can't I unmount my home directory when I exit?").
--
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
http://www.technion.ac.il/~tzafrir
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
