Date: Fri, 30 Jan 1998 01:56:56 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: joe.shevland@horizonti.com (Joe Shevland) Cc: hackers@FreeBSD.ORG, capriotti@geocities.com, capriotti0@hotmail.com Subject: Re: WebAdmin Message-ID: <199801300156.SAA10679@usr01.primenet.com> In-Reply-To: <199801292209.JAA05973@oznet11.ozemail.com.au> from "Joe Shevland" at Jan 30, 98 08:54:56 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Abouit suggestion on that "What I would like to see in a weAdimn tool", I > > found a couple of good points here: [snip] > > Now one question : if this could turn into a general admin tool, why not > > use Java (no flames, I beg !). > > None from me today :-). I think it'd be a good idea. One downfall with this > is the current version of the JDK (not the beta 1.2, but 1.1.5, I think) > will only allow connections from the client back to the server running the > httpd, using applets (unless you digitally sign the little beasties). > My original thoughts were not about post-install configs but this latest > stream seems the way to go (too many variables to be assumed to design a > Java/HTML/GUI installation cousin to sysinstall). > As far as security goes, this admind would have to have superuser > permissions, would it not? 1) Authenticate to the httpd server. This authentication makes you root for the purposes of the session. 2) Run JAVA plugin on the server. In this plugin, you have: A) Administration classes B) HTML classes C) Glue code in the form of CGI applets that present administration classes via (B), and accept input via B, which are then committed/denied by the admin classes. This is pretty trivial, since HTML classes already exist; You will need to write the FreeBSD admin classes to operate against FreeBSD databases that encompass objects like "users". 3) For command line, you run a JVM; either Sun's JRE, or Kaffee, whichever you can get the licensing resolved on. You then: A) Use the same administration classes from 2.A, above B) Use command line argument parsing classes C) Glue code in the form of CGI applets that present administration classes via (B), and accept input via B, which are then committed/denied by the admin classes. If you do this correctly, the code in 3.C is identical to that in 2.C. To do this, you would implement both (B)'s as instances subclassed off of a pure virtual UI class. 4) For text windowed UI, you have: A) Use the same administration classes from #.A and 2.A, above. B) Use text windowed UI dialog parsing classes C) Glue code in the form of CGI applets that present administration classes via (B), and accept input via B, which are then committed/denied by the admin classes. If you do this correctly, the code in 4.C is identical to that in 3.C and 2.C. To do this, you would implement all three (B)'s as instances subclassed off of a pure virtual UI class. This would all be a lot easier if all FreeBSD configuration information went to one place, and was accessed via one set of methods. Perhaps the LDAP methods, which are freely downloadable from the NetScape developer resources page at www.netscape.com? The massive number of FreeBSD databases need not change for this to work. FreeBSD could keep its fear of change and its proliferation of hundreds of incompatible text file and database formats, if it wanted to. You can write any LDAP back end you want to, including one that would allow you register multiple databases to manage various parts of the LDAP tree. Finally, for boot and local usage, you would probably want to implement a native access to the LDAP methods. This would let you directly access the database data, instead of requiring that you get your net up before you can set up your net (catch 22). 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?199801300156.SAA10679>