Date: Tue, 23 Jun 1998 17:47:00 +0200 (SAT) From: Peter van Heusden <pvh@leftside.wcape.school.za> To: freebsd-hackers@FreeBSD.ORG Subject: Adding a new user interface to FreeBSD administration Message-ID: <Pine.BSF.3.95.980623170004.4982C-100000@leftside.wcape.school.za>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980623170004.4982C-100000>