Date: Mon, 8 Jul 1996 15:39:49 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jim@starshine.org (Jim Dennis) Cc: terry@lambert.org, gpalmer@FreeBSD.ORG, ron@infi.net, freebsd-questions@FreeBSD.ORG Subject: Re: SysAdmin Tools - ideas wanted Message-ID: <199607082239.PAA22703@phaeton.artisoft.com> In-Reply-To: <199607060818.BAA06119@starshine> from "Jim Dennis" at Jul 6, 96 01:18:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I'd prefer to see an implementation that provided the front-end > and had that front end build a command line (or series of command > lines). > > Then the interface could allow the admin to look at the > command-line (did my menu selections translate to the sort > of command I would have used?) allow verification or editing > and it can log the commands that were issued. [ ... ] > Not separate -- build "in front of" (from which we get the > term "front end"). The previous, indeed, implies seperate. I was considering that the UI would invoke the command line utility and effectively *ask* the utility for it's UI schema, and implement certain UI-favoring command batching. However, they will in fact be independent by this action. For instance: ============================================================================ # uadmin uadmin> SHOW SCHEMA TITLE "User Administration" MENU TITLE "File" ITEM "Exit" EXIT END MENU TITLE "Users" ITEM "Show Users..." DIALOG user_show ITEM "Add User..." DIALOG user_add ITEM "Delete User..." DIALOG user_del END MENU TITLE "Groups" ITEM "Show Group..." DIALOG group_show ITEM "Add Group..." DIALOG group_add ITEM "Delete Group..." DIALOG group_del END MENU TITLE "Shells" ITEM "Show Shell..." DIALOG shell_show ITEM "Add Shell..." DIALOG shell_add ITEM "Delete Shell..." DIALOG shell_del END DIALOG user_show_d TITLE "Detailed information for user $1" LIST FROM COMMAND "SHOW USER $1 VERBOSE" BUTTON "Done" RETURN CANCEL DIALOG user_show TITLE "Show Users" BUTTON "Ok" RETURN CANCEL BUTTON "Show details..." DIALOG user_show_d $pick PICKONE pick FROM COMMAND "SHOW USER *" END END DIALOG user_del_confirm TITLE "Delete Users WARNING "This process can not be reversed" LIST $1 BUTTON "Cancel" RETURN CANCEL BUTTON "Delete" RETURN ACCEPT END DIALOG user_del TITLE "Delete User" BUTTON "Cancel" RETURN CANCEL BUTTON "Delete" IF DIALOG user_del_confirm $pick == ACCEPT THEN RETURN ACCEPT PICKMANY pick FROM COMMAND "SHOW USER *" COMMAND "DELETE USER $pick NOCONFIRM" END END BEGIN MENU "Delete User" ... ============================================================================ The UI has some choices in terms of presentation, but not in terms of organization. > > I'd like to see one program for a front end, and multiple tools > > that get invoked as a result of front end manipulation. > > > > Tcl/tk are OK for the fornt end tool, but not the backend implementation. > > Some parts of the back end might be implemented as 'expect' > scripts. This should be *strongly* discouraged. One could envision placing the front end on a client system and communicating via a "start this command" protocol over a transient session. For instance, you could consider a CGI script for translation to HTML using server scripting to do administration. This type of thing needs to be embeddable. For instance, say I wanted to build a print engine that was administerable via HTML, and I wanted to use FreeBSD as a base.. > > Any opinions in this posting are my own and not those of my present > > or previous employers. > > I find this disclaimer amusing since you seem to be posting > from your own domain. Simple CYA. My mail exchanger is my employer. Regards, 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?199607082239.PAA22703>