From owner-freebsd-hackers Tue Jun 23 08:51:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07096 for freebsd-hackers-outgoing; Tue, 23 Jun 1998 08:51:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from picasso.wcape.school.za (picasso.wcape.school.za [196.21.102.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA07073 for ; Tue, 23 Jun 1998 08:50:56 -0700 (PDT) (envelope-from pvh@leftside.wcape.school.za) Received: from uucp by picasso.wcape.school.za with local-rmail (Exim 1.92 #2) for freebsd-hackers@freebsd.org id 0yoVLO-00041a-00; Tue, 23 Jun 1998 17:50:50 +0200 Received: from localhost (pvh@localhost) by leftside.wcape.school.za (8.8.8/8.8.4) with SMTP id RAA05348 for ; Tue, 23 Jun 1998 17:47:01 +0200 (SAT) Date: Tue, 23 Jun 1998 17:47:00 +0200 (SAT) From: Peter van Heusden To: freebsd-hackers@FreeBSD.ORG Subject: Adding a new user interface to FreeBSD administration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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