From owner-freebsd-hackers Tue Jan 27 18:39:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18365 for hackers-outgoing; Tue, 27 Jan 1998 18:39:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18342 for ; Tue, 27 Jan 1998 18:39:48 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id SAA20554; Tue, 27 Jan 1998 18:52:05 -0800 Date: Tue, 27 Jan 1998 18:52:03 -0800 (PST) From: Alex Belits To: Adam Turoff cc: hackers Subject: Re: Admin GUI tool (was: RE: /usr/src/release/sysinstall needs YOU . :-)) In-Reply-To: <34CEB621@smginc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk On Tue, 27 Jan 1998, Adam Turoff wrote: > If you want to start writing a nifty GUI admin tool, then great. The > admin > tools that come with AIX are supposed to be well worth it. (Not having > used AIX I can't confirm/deny this assertion.) AIX SMIT worth it only because AIX itself has all administration done by large number of command-line utilities that edit text and simultaneously binary database, and none of those utilities have anything to do with Unix. If AIX had human-usable configuration files, vi will be more useful. And yes, SMIT (both Motif and curses-based interfaces) is a simple menu/form system that composes arguments for those utilities and processes its output only to display it as some list -- it can be done in HTML easier. > If it were MY FreeBSD box and MY GUI admin tool, I'd probably want it > written in tcl/tk. It's relatively low overhead, and the > source/interpreter > are in the public domain. No worrying about getting the proper JDK build > statically linked against the proper X libs, etc. Red Hat Linux distribution has exactly that, but its installation program is entirely text-based -- and considering that Linux distribution is supposed to work on notebooks with all kinds of weird hardware. RH 5.0 installer did everything well on my Micron TransPort XPE, but at the end royally screwed up X configuration. Since it happened on already working system, it was possible to reboot, then manually configure X. Even though one can do things the XFree86 installer way (starting with the most safe mode), non-X-based installer still will be nicer and safer. > It would also be nice if there was a curses-style interface as well. > > Python might also be a reasonable candidate. Perl/tk would require that > tk be installed by default with every FreeBSD perl installation - not > something you can realistically expect. > > As for web based administration, you're right. It has its uses, but > unless > done very well, it can be very clumsy and insecure. Any administration tool, unless done very well, will be very clumsy and insecure. HTTP has the advantage that it really can be started on anything and use anything from lynx to netscape as a client. Of course, it has huge number of features to misuse, but if done well it works well on everything. Security depends entirely on the client authentication, and if one uses localhost for installation and local configuration, and ssh forwarding for remote one (no, I don't have SSL-capable HTTP server on every box I use), it's really hard to make the system insecure if any HTTP authentication is used. > The java approach > just seems way too heavyweight for a free OS these days. If it were > Slowlaris, where you had amazing Java support in the base OS, that > would be a different story. Solaris is a heavyweight thing in itself, no one will notice if they will rewrite the whole CDE in java and ship it with every box. As for java security, it will add none because java is relatively secure as the source of problems for the host system, it runs on -- the harm that can be done to anything it handles entirely depends on the programmer and, in the case of remote administration, on the protocol used. -- Alex