Date: Tue, 23 Jun 1998 11:36:27 -0600 (MDT) From: Atipa <freebsd@atipa.com> To: Peter van Heusden <pvh@leftside.wcape.school.za> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration Message-ID: <Pine.BSF.3.96.980623112639.12303B-100000@altrox.atipa.com> In-Reply-To: <Pine.BSF.3.95.980623170004.4982C-100000@leftside.wcape.school.za>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD Registry? Well, you can look to MS for how NOT TO DO IT. I think that an object-based heirarchy is appropriate, but is should not be byte-compiled. In the event of ld/lib failures, one would need to navigate w/o any dynamic utilities (like a web server, visual editor, etc.). The "database" should be ASCII, and lean (like rc.conf, resolv.conf, etc., etc.). I don't see why you would need to cahnge any of these type files. In the case of UUCP/PPP/getty/etc. types of conflicts, I'd say just make am ASCII resource file, and add to it only problems like this one that may arise. No need to reinvent the wheel. Just my $.02. I think it is a good and needed plan, but it should not sacrafice the stability of a system, which is paramount. I think the slickest way to have a good text-modifying web interface is w/ Brent Welch's tclhttpd, available from sunscript.sun.com, or from scriptics.com. It is a really nice way to imbed httpd into all type of interfaces. Kevin On Tue, 23 Jun 1998, Peter van Heusden wrote: > Having recently worked on a WWW oriented user interface for FreeBSD, and > looked at some recent work on similar projects, I've been thinking about > the problems of providing an alternative interface to configuring FreeBSD > (alternative to vi, that is). > > Basically, the problem operates on 2 levels - the first, and easiest to > solve, is automating the editing of various configuration files > (/etc/rc.conf, /etc/crontab and others). The second problem is structuring > changes to the configuration in a meaningful way - for instance, if a > modem is connected to the computer on /dev/cuaa1, both PPP and UUCP will > probably want to talk to /dev/cuaa1. > > One could 'solve' the second problem by locking configuration file changes > into an 'object model' - e.g. your configuration is only valid if it fits > rigidly to some other 'model' of how your computer is set up - i.e. the > port your UUCP talks to must be defined as a port that a modem is on in > some database (AIX ODM/Windows Registry/whatever). This 'solution' > effectively makes the textual configuration files just a representation of > some other database. > > But FreeBSD people want to live in both worlds - new users often want the > ease of use of a structured configuration environment, advanced users > want to be able to do whatever they want, even if it doesn't appear > 'sane'. > > After thinking about this, I concluded that maybe the best approach would > be to think of two levels of representation, and resolve the conflicts (if > any) between them using 'hints'. What this would mean in practice is: > > 1) A set of tools can convert all the textual config files into > some abstract representation (variable = value for most). Textual config > files are extended by adding markup (maybe in the comments) which links > various variables to the database specified below. (e.g. > network_interfaces should somehow 'know' what the system 'knows' about > existing network interfaces on the computer) > > 2) A database is maintained about the configuration of the system. This > database contains both information gleaned in the boot process (e.g. we > have a sio0, sio1) and information specified by the user (a modem is > attached to sio1). > > 3) A set of tools allow the user to alter the configuration of the text > files, suggesting reasonable values from the database. In the case that > changes to the text files have been made (e.g. with vi) which appear to be > illogical (e.g. the modem init string for PPP is different to the one > specified for UUCP), the user is warned of this inconsistency, and can > either a) make the values consistent, or b) tell the system that the > inconsistency is intentional, in which case the database stores a 'hint' > telling itself not to warn the user about the 'problem' again. > > Of course, the implementation of this is going to be quite complex - for > instance, in UUCP, the 'port' line in the 'sys' file refers to a 'port' > defined in the 'port' file, which refers to a 'dialer' specified in the > 'dial' file - automating the admin of that is hardly changing 1 variable. > (Although it would possibly be made easier if a whole range of 'common' > values for ports are pre-defined in the 'port' file) > > Anyway, the above is mostly random musing towards trying to get a solution > for this problem - I'd appreciate anyone's comments. > > Peter > -- > Peter van Heusden | Computers Networks Reds Greens Justice Peace Beer Africa > pvh@leftside.wcape.school.za | Support the SAMWU 50 litres campaign! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980623112639.12303B-100000>