Wild-eyed thinking aloud: Python System Management Infrastructure

[Quinn Dunkan]

>>Complexity:  With an ssh link you can use plain text.  Over http you
>>have to use complicated html and use some giant bloated browser to see
>>it.  I use systems that have no web browser, but do have ssh.  And a
>>web thing is going to have some complicated nest of cgi scripts that
>>will wind up doing the same stuff you can do directly with a shell.
>
>The flip side is that if you actually want a UI, using HTML and a
>browser is the simplest way of doing that.  Also, it doesn't need to be
>either/or with ssh vs. HTML; you could ssh in and use Lynx, which is
>hardly a bloated browser.

My lynx has a text segment of 978K, which is pretty bloated, especially
considering that it won't do tables which could make your forms pretty ugly.
But that's not really the point (you could use w3m which does do tables and
is 223K) (they also both assume cursor addressing, which isn't universal, but
that's still not the point).  Presumably you have a reasonable machine to
sysadmin from.

Anyway, provided that your definition of "UI" is "web form", then yes, HTML is
probably the easiest and simplest way to do that.

>>Speed:  Web forms are slow and clumsy.
>
>Not under Lynx.  ;-)  People are sometimes amazed at just how quickly I
>can fill out a web form.

I didn't mean that specifically web-forms-under-netscape were slow and clumsy,
but that web forms in general are slow and clumsy, as illustrated below:

>Let's say you're creating new user accounts, and there's a list of ten
>boolean options that are standard (e.g. does this user get sudo
>access?).  Presenting a list of checkboxes in HTML is much easier to
>manage on the UI side than just about any other method.

I think it would be easier, more flexible, and faster to type:

PATH=$psmi_home/bin:$PATH
n() {
    new_user $1
    sudo_register $1
    etc.
}
for u in `cat new_user_list`; do n $u; done

... rather than manually clicking (or tabbing, for lynx or w3m) through a web
form 15 times.  And someday you're going to want to set some of the 15
not-so-standard options, or, more likely, create your own option.  I already
know how to use a shell, why make me learn a whole new web-maze / interface?

If the whole point is to automate system interaction and issue higher-level
commands, why lock that level at whetever level you write your web forms at?
The job is varied enough that predicting the "right" functionality to give
access to in a form will be hard to get right, if possible at all.

It would be possible to create a system consisting of a bunch of small
programs, and then create a seperate tool that takes a list of commands and
states and generates the html and cgi glue to make a form out of it.  You'd
also gain a useful (?) general purpose tool.  Going the other direction would
be much more difficult and would add another brittle layer in between you and
what actually happens.