From owner-freebsd-config Sun Apr 19 10:25:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22679 for freebsd-config-outgoing; Sun, 19 Apr 1998 10:25:16 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles236.castles.com [208.214.165.236]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA22579 for ; Sun, 19 Apr 1998 17:25:05 GMT (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA01985; Sun, 19 Apr 1998 10:22:17 -0700 (PDT) Message-Id: <199804191722.KAA01985@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: allen campbell cc: config@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. In-reply-to: Your message of "Sun, 19 Apr 1998 04:24:29 MDT." <199804191024.EAA10069@const.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Apr 1998 10:22:15 -0700 From: Mike Smith Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > > How do you address an assertion which says dependency on a database > reduces robustness because of, for instance, database corruption? How do you address an assertion which says dependency on configuration files reduces robustness because of, for instance, file corruption? > Do you disregard the assertion based on evolutionary necessity > ('bite the bullet') or do you dispute that there is any significant > compromise at all? Corruption can come from at least couple of sources: - Faulty applications. - Backing store (filesystem) corruption. - User error. In the case of plain text files, application faults are less an issue (most text editors work OK), but the others remain an issue. With a database, especially in the early stages, you have to worry more about the stability of the application(s), but less about the user being able to nuke things. By leveraging a known-stable database engine (the Umich LDAP server), we hope to reduce the application-fault vulnerability profile. > Does a configuration database imply a client/server design and, > therefore, a daemon to implement the server, or do you expect that > a static/shared library would allow the client direct access? Client/server is highly desirable, but starting the server early enough to be useful is a bit of a challenge. > The > former provides for a very thin client and powerful concurrency > control (such as signaling registered clients when the hostname > changes.) The latter has the appeal of not requiring an daemon > which would be tough to support in minimalist applications. Both > perhaps? A read-only client library would have numerous advantages for minimalist applications, yes. > Different parts of the configuration hierarchy have different > security requirements and this will ultimately require close > integration with the kernel for enforcement, authentication, etc. > How does that square with a user mode subsystem such as LDAP? The Umich server supports the use of password-protected ACLs. In addition, one can use SSL to secure communications with the server. Combining this with FreeBSD's ability to unequivocally ascertain the credentials of the process at the other end of an IPC channel, an end-to-end secure and authenticated pipe can be constructed from a local application, via a local forwarder to a remote parameter store. > As a database applications developer, I have learned that there is > little integration between host system security and database security > in contemporary SQL database systems.) The real challenge as we move to a distributed parameter store is to shift perspective back a little further and see that database security encompasses the entire network, not just a single host. But you're right in this case - the system's security model must be incorporated. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sun Apr 19 14:33:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16268 for freebsd-config-outgoing; Sun, 19 Apr 1998 14:33:54 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA16182; Sun, 19 Apr 1998 21:33:24 GMT (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA18152; Sun, 19 Apr 1998 14:33:18 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd018111; Sun Apr 19 14:33:15 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA14057; Sun, 19 Apr 1998 14:33:12 -0700 (MST) From: Terry Lambert Message-Id: <199804192133.OAA14057@usr08.primenet.com> Subject: Re: Discussion : Using DHCP to obtain configuration. To: allenc@verinet.com (allen campbell) Date: Sun, 19 Apr 1998 21:33:12 +0000 (GMT) Cc: hackers@FreeBSD.ORG, config@FreeBSD.ORG In-Reply-To: <199804191024.EAA10069@const.> from "allen campbell" at Apr 19, 98 04:24:29 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > > > Oh.. and while I'm dreaming, how about using portalfs or similar as > > > such: mount /etc with portalfs and have a translator present all of > > > the data from the database in traditional format. > > > > This is a *terrifically* cool idea! > > This simply obsoletes any idea to-date that I know of for supporting > the legacy system. [ ... ] > Terry, I have followed your advocacy of LDAP (or a similar alternative) > for some time now and I have some questions. OK! Let me point out here that though I think LDAP is the best fit, what we are really talking about is a attribute name/attribute value pair, and whether it's implement with LDAP, ACAP, or as an extenstion to SMTP, it's pretty irrelevent. The wins are independent of the implementation details. > How do you address an assertion which says dependency on a database > reduces robustness because of, for instance, database corruption? > Do you disregard the assertion based on evolutionary necessity > ('bite the bullet') or do you dispute that there is any significant > compromise at all? I dispute that there is a significant compromise. There *is* a potential compromise. Opponents of using a database design point to partial corruption equalling partial recoverability in the flat file. I would point out to this position that the flat files use the underlying file system, which has the same semantics as those that have been proposed for the user space code. The assumption here seems to be that you can't build a robust, user space transactioning system on top of a robust, kernel space transactioning system. It's pretty easy to prove this assumption wrong from a technical perspective. We can take the example of pwd_mkdb, the program that synchronizes the passwd/pwd.db files. It has exactly the same issues to deal with. In fact, pwd_mkdb is a rather nifty example, because it shows us a feature that we can't get anywhere else: schema enforcement. If the proposed change would render the database inconsistent, the change is refused. The compromise lies in the non-robustness assumption; it not real, because it's silly to assume that people who *can't* write robust user space code *can* write robust kernel space code. It's pretty much binary: they can or the can't, and the user/kernel qualification is irrelevent. > Does a configuration database imply a client/server design and, > therefore, a daemon to implement the server, or do you expect that > a static/shared library would allow the client direct access? The > former provides for a very thin client and powerful concurrency > control (such as signaling registered clients when the hostname > changes.) The latter has the appeal of not requiring an daemon > which would be tough to support in minimalist applications. Both > perhaps? I would prefer the client/server design. This simplifies the local database access by making it the same as the remote database access. This skirts serialization issues that would otherwise have to be addressed. Mostly these are concerned with multiple writer issues, but there are also transactioning issues that could be addressed at the protocol level, but not enforcible in the direct access case. There are also issues of security model enforcement if you allow local access via some other method. I think that if there is one access point, this enforces a single security model. You can easily get credentials of the "remote" process over a POSIX domain socket in FreeBSD at this point, so "root" authentication is pretty trivial in the boot stage. You could do the same with the loopback interface; the real issue to deal with here is whether or not you will force the existance of full-blown networking. I think it would be a mistake to *require* IPv4 (for example). At the same time, the BSD IPC model is sockets and/or named pipes, and the underlying implementation is tied to the POSIX domain. Short of rejecting the BSD IPC model in favor of the System V model (a bad idea), I can't see not requiring a formal IPC mechanism of *some* kind. The final argument in favor of a client/server model is "very thin clients". This might include printers, scanners, login servers, and so on, which are not very intelligent on their own, but need the services of a more intelligent device (or would function better with the services of such a device than they would function without). This argument also favors the use of SLP (Service Location Protocol), ala the RFC (see http://www.srvloc.org ) after DHCP or 10/8 address configuration to locate such things as document stores (where a FAX machine that isn't a printer, for example) could store incoming documents. > Different parts of the configuration hierarchy have different > security requirements and this will ultimately require close > integration with the kernel for enforcement, authentication, etc. > How does that square with a user mode subsystem such as LDAP? Well, I addressed a little of this above. If you have followed the SMBFS discussions in the past, the rest can be very effectively handled through a credential management interface attached to the login session. The most convenient place to put this seems, to me, to be in a UNIX session manager. All credential requests from the kernel to a process would be indirected through the session manager process, which could choose to answer the requests on the user's behalf. This leads to three models: 1) User query, where the session manager butts in and asks the user for the credential. This is best suited to X and to the local console, and such other devices as could refresh the screen transparently without the application having to know the query has taken place. 2) Operation time query. For example, the mount system call could return ENEEDAUTH, and the mount command could, if isatty(fileno(stdout)) was true, interrogate the user for a password. 3) Preload, where the credential information is preloaded by the user before the operation is attempted. This is less useful interactively, but would allow a "password cache" type facility. Together, these models appear to address the rest of your issues for coupling of the security model. It wouldn't be necessary to require a session manager initially; one is only required when you start trying to do tricky stuff that relies on you already having the associated infrastructure. For example, you'd need something like this to hold an ACL reference if you wanted to let non-root user manage who had accounts, etc.. I personally dislike the idea of splitting administrative control into functional domains (in that direction lies SCO ODT and UNIX ES), but I agree that it shouldn't be architected against, in case someone else wants to implement it for some strange reason. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sun Apr 19 15:02:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22105 for freebsd-config-outgoing; Sun, 19 Apr 1998 15:02:38 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA22080 for ; Sun, 19 Apr 1998 22:02:27 GMT (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA23327; Sun, 19 Apr 1998 15:02:24 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd023306; Sun Apr 19 15:02:22 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA15594; Sun, 19 Apr 1998 15:02:17 -0700 (MST) From: Terry Lambert Message-Id: <199804192202.PAA15594@usr08.primenet.com> Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' To: kpielorz@tdx.co.uk (Karl Pielorz) Date: Sun, 19 Apr 1998 22:02:17 +0000 (GMT) Cc: tlambert@primenet.com, allenc@verinet.com, config@FreeBSD.ORG In-Reply-To: <353A70A6.E90B3645@tdx.co.uk> from "Karl Pielorz" at Apr 19, 98 10:46:14 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Two things... > > 1. The subject line on this message is the worst I've seen in a long time - > Will whoever replies next tidy it up properly (like I didn't! :-) Yes. > 2. This has been cross-posted to hackers & config... I've only posted it to > hackers - as looking back that's where most the messages went... I'm all to > willing to move to Config if that's where it's / were meant to be! This was supposed to only go to config, like was suggested in the message I replied to. > Thus you'd get a couple of 'dodgy' records in your text dump which you could > edit by hand, then nuke the config database - and re-import the text file > once it was cleaned up... > > It would be nice to see a config database done 'the propper way', i.e. not > liable to application corruption etc. - perhaps even with 'descriptions' for > all the records it holds... ;-) These two paragraphs are not unrelated. If you use an API with get/set semantics, and it does the set as a transaction, then you are not liable to corruption unless your physical media goes bad. If the physical media goes, it doesn't matter how it's implemented. Clearly, you would need to take the same care in backing up a binary file as you do in backing up a text file in case of physical failure. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sun Apr 19 16:00:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00152 for freebsd-config-outgoing; Sun, 19 Apr 1998 16:00:34 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA00133; Sun, 19 Apr 1998 23:00:27 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id QAA29933; Sun, 19 Apr 1998 16:00:21 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Terry Lambert cc: allenc@verinet.com (allen campbell), hackers@FreeBSD.ORG, config@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. In-reply-to: Your message of "Sun, 19 Apr 1998 21:33:12 -0000." <199804192133.OAA14057@usr08.primenet.com> Date: Sun, 19 Apr 1998 16:00:21 -0700 Message-ID: <29930.893026821@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > and whether it's implement with LDAP, ACAP, or as an extenstion to > SMTP, it's pretty irrelevent. The wins are independent of the SMTP? :-) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sun Apr 19 16:25:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06531 for freebsd-config-outgoing; Sun, 19 Apr 1998 16:25:45 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA06516 for ; Sun, 19 Apr 1998 23:25:38 GMT (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.8.8/8.8.8) with ESMTP id AAA00506 for ; Mon, 20 Apr 1998 00:25:33 +0100 (BST) (envelope-from kpielorz@tdx.co.uk) Message-ID: <353A87D5.6F4A8737@tdx.co.uk> Date: Mon, 20 Apr 1998 00:25:09 +0100 From: Karl Pielorz Organization: TDX X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: config@FreeBSD.ORG Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' References: <199804192202.PAA15594@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Terry Lambert wrote: > This was supposed to only go to config, like was suggested in the > message I replied to. True, I guess we get to see how many people are actually reading -config now... ;-) > > Thus you'd get a couple of 'dodgy' records in your text dump which you could > > edit by hand, then nuke the config database - and re-import the text file > > once it was cleaned up... > > > > It would be nice to see a config database done 'the propper way', i.e. not > > liable to application corruption etc. - perhaps even with 'descriptions' for > > all the records it holds... ;-) > > These two paragraphs are not unrelated. Sort of... I see your valid point below... > If you use an API with get/set semantics, and it does the set as a > transaction, then you are not liable to corruption unless your > physical media goes bad. Ok - granted - Maybe we should be more concerned with 'applications' corrupting the database - and if so have a nicer way to correct it (Ok, read - 'anyway' to correct it) unlike Windows '95 / NT - in which the registry is largely seen as an unindexed black whole... > If the physical media goes, it doesn't matter how it's implemented. True... Having revised my answer though - I'd still like to see a nice way of importing / exporting the data, and editing it (to patch it up when things go wrong with applications etc.) The last thing we want is the 'perpetually' growing mess that my NT machine has on it, called a 'registry' (The install is about 2 months old, and already the registry is up to just under 5mb - It usually 'lasts' about 6 - 8 months before all the 'weird' things start happening (CD players opening in too a small window etc.) > Clearly, you would need to take the same care in backing up a binary > file as you do in backing up a text file in case of physical failure. Granted - I just can't figure out why I always feel more 'secure' with text files (and a lot of other people appear to feel the same)... I'm sure I'll get used to it - especially when it's done 'right'... Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sun Apr 19 16:54:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA13445 for freebsd-config-outgoing; Sun, 19 Apr 1998 16:54:50 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA13393; Sun, 19 Apr 1998 16:54:38 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199804192354.QAA13393@hub.freebsd.org> Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' In-Reply-To: <353A87D5.6F4A8737@tdx.co.uk> from Karl Pielorz at "Apr 20, 98 00:25:09 am" To: kpielorz@tdx.co.uk (Karl Pielorz) Date: Sun, 19 Apr 1998 16:54:36 -0700 (PDT) Cc: config@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Karl Pielorz wrote: > Terry Lambert wrote: > > If you use an API with get/set semantics, and it does the set as a > > transaction, then you are not liable to corruption unless your > > physical media goes bad. > > Ok - granted - Maybe we should be more concerned with 'applications' > corrupting the database - and if so have a nicer way to correct it (Ok, read > - 'anyway' to correct it) unlike Windows '95 / NT - in which the registry is > largely seen as an unindexed black whole... more than once i have damaged my computer's configuration enough that i was unable to complete booting. only being able to edit the flatfiels saved me from having to rip out the internal disk and connect that disk to another machine. any registry or LDAP database or what have you, needs an ascii "save my ass please" mode. without that its a great leap backward into the abyss ;) jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sun Apr 19 18:52:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA05729 for freebsd-config-outgoing; Sun, 19 Apr 1998 18:52:35 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA05710 for ; Mon, 20 Apr 1998 01:52:29 GMT (envelope-from softweyr@xmission.com) Received: from slc402h.modem.xmission.com (xmission.com) [166.70.2.148] by mail.xmission.com with esmtp (Exim 1.82 #2) id 0yR5kr-0005pB-00; Sun, 19 Apr 1998 19:52:24 -0600 Message-ID: <353AAB38.2C5021FF@xmission.com> Date: Sun, 19 Apr 1998 19:56:09 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Karl Pielorz CC: config@FreeBSD.ORG, terry@lambert.org Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' References: <199804192202.PAA15594@usr08.primenet.com> <353A87D5.6F4A8737@tdx.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Karl Pielorz wrote: > > Terry Lambert wrote: > > > This was supposed to only go to config, like was suggested in the > > message I replied to. > > True, I guess we get to see how many people are actually reading -config > now... ;-) There are still a few of us. ;^) > > If you use an API with get/set semantics, and it does the set as a > > transaction, then you are not liable to corruption unless your > > physical media goes bad. > > Ok - granted - Maybe we should be more concerned with 'applications' > corrupting the database - and if so have a nicer way to correct it (Ok, read > - 'anyway' to correct it) unlike Windows '95 / NT - in which the registry is > largely seen as an unindexed black whole... > > > If the physical media goes, it doesn't matter how it's implemented. > > True... Having revised my answer though - I'd still like to see a nice way > of importing / exporting the data, and editing it (to patch it up when > things go wrong with applications etc.) > > The last thing we want is the 'perpetually' growing mess that my NT machine > has on it, called a 'registry' (The install is about 2 months old, and > already the registry is up to just under 5mb - It usually 'lasts' about 6 - > 8 months before all the 'weird' things start happening (CD players opening > in too a small window etc.) One thing that Mike Smith and I discussed last year was the idea of being able to key modifications to the system configuration to packages. This way, if you added a package and *it* changed the system configuration, it could back out the changes on de-install, or back them out and reapply new ones on upgrade. While this is an admirable goal, when you think about it in detail it becomes obvious that this is a very difficult job to do well. How to handle changes that were made after your changes is a prime example of problems that haven't been addressed that well. The simplest way to address this, I feel, is to stick with text configuration files and use RCS to control the revisions. You can do some mighty clever things with tags, or with checkin comments, and RCS can do some mighty clever tricks with versions of files. What RCS cannot do natively, a little clever programming can work around, like a program that can take one revision out of the middle of a line by backing up to the previous revision and patching forward all the revisions *except* the one you're trying to get rid of. RCS also allows you to specify *why* you made a particular change, and the package and port installation tools could be upgraded to consitently comment on their actions in changing the configuration as well. > > Clearly, you would need to take the same care in backing up a binary > > file as you do in backing up a text file in case of physical failure. > > Granted - I just can't figure out why I always feel more 'secure' with text > files (and a lot of other people appear to feel the same)... Because the backups are so persistent, and so easy to implement. A text configuration allows an old e-mail message with the contents, or even a printout stuffed in your bottom desk drawer, to be a reliable backup in case of catastrophic failure. This is rarely, if ever, true with a binary file... > I'm sure I'll get used to it - especially when it's done 'right'... ...unless it's done right. Think of the 'vipw' model: your data is stored in a binary file with whatever structure makes sense for the data. *One* of the common access methods is to write a program that can dump this structured binary data into a structured text file, and read the information back from the structured text file. Then *one* of your user interfaces can be as simple as implementing a script program that locks the binary file, exports the data, runs the user's preferred editor, and imports the data iff the user modified the file. Sounds kinda familiar, doesn't it? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sun Apr 19 20:49:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA04181 for freebsd-config-outgoing; Sun, 19 Apr 1998 20:49:24 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from zippy.dyn.ml.org (garbanzo@seoul-194.ppp.hooked.net [206.169.228.194]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA04029 for ; Mon, 20 Apr 1998 03:49:14 GMT (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.8/8.8.7) with SMTP id UAA08816; Sun, 19 Apr 1998 20:49:08 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sun, 19 Apr 1998 20:49:07 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: Karl Pielorz cc: config@FreeBSD.ORG Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' In-Reply-To: <353A70A6.E90B3645@tdx.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Karl Pielorz wrote: [...] > The database was like the 'dreaded registry', i.e. proprietry format etc. - > But what it did have (that really saved it's self!) was a number of > utilities for exporting the database out in text format, and for important > text files into the database - The database design was also pretty good as > well - i.e. if it did get corrupt (which it only did once) - the 'dump' > routines would get as far as the corruption - perhaps screw up a couple of > records - and then keep going with the others... Well, just to play the Devil's Advocate, Win95 (and probably NT to some extent) allow you to export and import registry data to and from text files (with the .reg extension). [...] - alex "Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Mon Apr 20 00:38:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA26221 for freebsd-config-outgoing; Mon, 20 Apr 1998 00:38:35 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26213; Mon, 20 Apr 1998 07:38:31 GMT (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id LAA00562; Mon, 20 Apr 1998 11:34:48 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id JAA23210; Mon, 20 Apr 1998 09:57:00 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id JAA00834; Mon, 20 Apr 1998 09:37:13 +0200 (CEST) Message-ID: <19980420093713.53639@deepo.prosa.dk> Date: Mon, 20 Apr 1998 09:37:13 +0200 From: Philippe Regnauld To: "Jonathan M. Bresler" Cc: config@FreeBSD.ORG Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' References: <353A87D5.6F4A8737@tdx.co.uk> <199804192354.QAA13393@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: <199804192354.QAA13393@hub.freebsd.org>; from Jonathan M. Bresler on Sun, Apr 19, 1998 at 04:54:36PM -0700 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Jonathan M. Bresler writes: > > Ok - granted - Maybe we should be more concerned with 'applications' > > corrupting the database - and if so have a nicer way to correct it (Ok, read > > - 'anyway' to correct it) unlike Windows '95 / NT - in which the registry is > > largely seen as an unindexed black whole... > > more than once i have damaged my computer's configuration > enough that i was unable to complete booting. [...] > any registry or LDAP database or what have you, needs > an ascii "save my ass please" mode. I thought this was where the Nifty Portal Hack came in -- with /etc a portal FS, and where doing "vi /etc/fstab" actually called up the right hooks in the DB, and presented to you an ascii file. (as in: scsi -p -e, f.e.) As for applications ruining the database, Terry did say, "enforce a schema" -- meaning no application should be allowed to submit a flawed change and get away with it -- just like pwd_mkdb. If it's corrupt, it's not validated. > without that its a great leap backward into the abyss ;) Yes, but think of the momentum gained! :-) -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Mon Apr 20 02:48:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA19383 for freebsd-config-outgoing; Mon, 20 Apr 1998 02:48:51 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (algae19.verinet.com [199.45.181.115]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA19362; Mon, 20 Apr 1998 09:48:44 GMT (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id DAA10086; Mon, 20 Apr 1998 03:48:42 -0600 (MDT) (envelope-from allenc) Date: Mon, 20 Apr 1998 03:48:42 -0600 (MDT) From: allen campbell Message-Id: <199804200948.DAA10086@const.> To: allenc@verinet.com, tlambert@primenet.com Subject: Re: Discussion : Using DHCP to obtain configuration. Cc: config@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199804192133.OAA14057@usr08.primenet.com> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > > > How do you address an assertion which says dependency on a database > > reduces robustness because of, for instance, database corruption? > > Do you disregard the assertion based on evolutionary necessity > > ('bite the bullet') or do you dispute that there is any significant > > compromise at all? > > I dispute that there is a significant compromise. > > There *is* a potential compromise. Opponents of using a database > design point to partial corruption equalling partial recoverability > in the flat file. > > I would point out to this position that the flat files use the > underlying file system, which has the same semantics as those > that have been proposed for the user space code. > > The assumption here seems to be that you can't build a robust, user > space transactioning system on top of a robust, kernel space > transactioning system. > > It's pretty easy to prove this assumption wrong from a technical > perspective. We can take the example of pwd_mkdb, the program > that synchronizes the passwd/pwd.db files. It has exactly the same > issues to deal with. > > In fact, pwd_mkdb is a rather nifty example, because it shows us > a feature that we can't get anywhere else: schema enforcement. If > the proposed change would render the database inconsistent, the > change is refused. > > The compromise lies in the non-robustness assumption; it not real, > because it's silly to assume that people who *can't* write robust > user space code *can* write robust kernel space code. It's pretty > much binary: they can or the can't, and the user/kernel qualification > is irrelevant. > I meant the question in regard to database integrity as opposed to schema data consistency. My ambiguity. My own experience with SQL database systems leads me to agree with you. A robust file system supporting a proven transaction engine makes for very solid system, even in the face of severe conditions such as power failure or inadequate resources. A database system also presents good opportunities for safeguards, such as replication and remote fail-over. The paranoid can make use of the configuration portal file system (configfs?) to squirrel away whatever they value most. :) > > > Does a configuration database imply a client/server design and, > > therefore, a daemon to implement the server, or do you expect that > > a static/shared library would allow the client direct access? The > > former provides for a very thin client and powerful concurrency > > control (such as signaling registered clients when the hostname > > changes.) The latter has the appeal of not requiring an daemon > > which would be tough to support in minimalist applications. Both > > perhaps? > > I would prefer the client/server design. > > This simplifies the local database access by making it the same as > the remote database access. I was thinking smaller because my interest in this is motivated by the need for a database which is up-gradable via automation, and to provide an abstraction layer against which multiple user interface tools could be authored. By themselves, these goals don't benefit much from a true transaction engine. As Mike described with his Romeo and Juliet model, client/server design is called for, but the minimalist in me notes that a server in this case does not have to be an actual daemon. Clearly there are goals beyond these that do benefit from a transaction engine and I agree that this is best. > If you have followed the SMBFS discussions in the past, the rest > can be very effectively handled through a credential management > interface attached to the login session. > > The most convenient place to put this seems, to me, to be in a UNIX > session manager. All credential requests from the kernel to a process > would be indirected through the session manager process, which could > choose to answer the requests on the user's behalf. Does anything similar to this currently exist that could be exploited for this need? I see your model is correct, but it is also a rather large cathedral. I agree (as you point out below) it is not required initially. > This leads to three models: > > 1) User query, where the session manager butts in and asks the > user for the credential. This is best suited to X and to > the local console, and such other devices as could refresh > the screen transparently without the application having to > know the query has taken place. > > 2) Operation time query. For example, the mount system call > could return ENEEDAUTH, and the mount command could, if > isatty(fileno(stdout)) was true, interrogate the user for > a password. > > 3) Preload, where the credential information is preloaded by > the user before the operation is attempted. This is less > useful interactively, but would allow a "password cache" > type facility. I envision something like a line mode 'registry' editor (configsh?) which would allow appropriate access to go unchallenged after authentication. In this case, 'Preload' would be very useful interactively, as the operator moved among domains in the hierarchy. The session manager would attempt to answer each challenge on behalf of configsh as the operator performed administration tasks. > It wouldn't be necessary to require a session manager initially; one > is only required when you start trying to do tricky stuff that relies > on you already having the associated infrastructure. Even if it only provides a simple security mechanism, it would probably be best if it existed from the start. > I personally dislike the idea of splitting administrative control > into functional domains (in that direction lies SCO ODT and UNIX ES), > but I agree that it shouldn't be architected against, in case someone > else wants to implement it for some strange reason. Somehow, all the domains eventually aggregate onto one person anyhow, whatever the strange reason. :) Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Mon Apr 20 07:26:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29365 for freebsd-config-outgoing; Mon, 20 Apr 1998 07:26:22 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from bamboo.verinet.com (allenc@bamboo.verinet.com [204.144.246.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA29232; Mon, 20 Apr 1998 14:25:49 GMT (envelope-from allenc@bamboo.verinet.com) Received: (from allenc@localhost) by bamboo.verinet.com (8.8.8/8.7.1) id IAA01654; Mon, 20 Apr 1998 08:25:46 -0600 Date: Mon, 20 Apr 1998 08:25:46 -0600 From: Allen Campbell Message-Id: <199804201425.IAA01654@bamboo.verinet.com> To: allenc@verinet.com, allenc@verinet.com, tlambert@primenet.com Subject: Re: Discussion : Using DHCP to obtain configuration. Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Mon Apr 20 07:41:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA02152 for freebsd-config-outgoing; Mon, 20 Apr 1998 07:41:47 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from fw.waterpik.com (fw.waterpik.com [208.146.241.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA01857 for ; Mon, 20 Apr 1998 14:39:24 GMT (envelope-from acampbell@fw.waterpik.com) Received: from WATERPIK-Message_Server by fw.waterpik.com with Novell_GroupWise; Mon, 20 Apr 1998 08:37:20 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 20 Apr 1998 08:36:55 -0600 From: Allen Campbell To: config@FreeBSD.ORG Subject: Carelessness Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Please forgive for my recent cross post to hackers and config. You will note the time stamp was 3:50 AM. It simply never crossed my dull and fuzzy mind to check the headers. Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Mon Apr 20 11:35:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05923 for freebsd-config-outgoing; Mon, 20 Apr 1998 11:35:19 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA05656 for ; Mon, 20 Apr 1998 18:34:37 GMT (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.8.8/8.8.8) with ESMTP id TAA14140 for ; Mon, 20 Apr 1998 19:34:26 +0100 (BST) (envelope-from kpielorz@tdx.co.uk) Message-ID: <353B9520.CEDABF26@tdx.co.uk> Date: Mon, 20 Apr 1998 19:34:08 +0100 From: Karl Pielorz Organization: TDX X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: config@FreeBSD.ORG Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' References: <199804192354.QAA13393@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Jonathan M. Bresler wrote: > > Karl Pielorz wrote > > Ok - granted - Maybe we should be more concerned with 'applications' > corrupting the database - and if so have a nicer way to correct it (Ok, read > - 'anyway' to correct it) unlike Windows '95 / NT - in which the registry is > largely seen as an unindexed black whole... > > more than once i have damaged my computer's configuration > enough that i was unable to complete booting. > only being able to edit the flatfiels saved me from having > to rip out the internal disk and connect that disk to > another machine. > > any registry or LDAP database or what have you, needs > an ascii "save my ass please" mode. > > without that its a great leap backward into the abyss ;) > jmb I'll second that... So whatever we end up with has to be runnable in a pretty 'minimal' environment... ;-) - i.e. the back end of a 1.44Mb fixit disk... I'm still not too sure I like the idea of 'binary' databases... One of the reasons I love unix at the moment is you can mostly pull it to bits with vi - I guess so long as we don't loose site of that (i.e. with good export / import stuff etc.) it should be OK... Kp -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Wed Apr 22 00:30:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA17993 for freebsd-config-outgoing; Wed, 22 Apr 1998 00:30:32 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (fern8.verinet.com [199.45.181.72]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA17984 for ; Wed, 22 Apr 1998 07:30:24 GMT (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id BAA13255 for config@freebsd.org; Wed, 22 Apr 1998 01:31:00 -0600 (MDT) (envelope-from allenc) Date: Wed, 22 Apr 1998 01:31:00 -0600 (MDT) From: allen campbell Message-Id: <199804220731.BAA13255@const.> To: config@FreeBSD.ORG Subject: Re: Config Databases In-Reply-To: <353B9520.CEDABF26@tdx.co.uk> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk [ The order of the quoted paragraphs has been reversed ] > I'm still not too sure I like the idea of 'binary' databases... One of the > reasons I love unix at the moment is you can mostly pull it to bits with vi > - I guess so long as we don't loose site of that (i.e. with good export / > import stuff etc.) it should be OK... I would like to share my thoughts on 'good export / import' here. The possibility of a portal file system which would export the various domains of the database as /etc/* files was mentioned. Several people, including myself, thought this was an excellent idea. At the same time, the ability to write to these pseudo-files and cause database updates occur was also offered. I have since formulated a few thoughts on this. The most obvious advantage of using the portal file system to export configuration data from the actual database is the transparency to existing software. Few modifications to existing, configuration dependent programs would be required to implement this. Another not-so-obvious advantage is concurrency; when some piece of global information changes, it should be reflected in all of the exported files automatically. Here we gain much of the benefit of a central configuration system with no modification to system software (although clearly not as good as if all dependent programs could automatically respond to dynamic changes.) So far, all of the above is accomplished with a _Read-Only_ portal file system ('configfs' henceforth :) .) Making this mechanism write-able is where things get complicated. My own experience in applications development tells me that it is far simpler to author a reporting application than a data entry application. I think that difference is well demonstrated by the difficulty posed in creating the parsers and data validation software necessary to support every conceivable format found lurking in /etc and then merging all of this into configfs, whereas only reading the database to emulate the original file should be relatively trivial. There is another possibility which should be considered. The current password database system could be generalized to support nearly any configuration file. Currently we have several front-ends to the password database which handle account administration very smoothly. Chpass(1), passwd(1) and vipw(1) all allow you to manipulate the password database indirectly, and then update 'binary' databases via pwd_mkdb. For some time after I began using FreeBSD, I was completely unaware this was taking place. I didn't find out until I noticed that an entry made directly into /etc/passwd with vi had no effect. If this model (I'll call it the translation model) were generalized, I see where we gain in four ways. First, configfs remains read-only. This provides for the possibility that it may exist within our lifetimes. :) Second, the data reflected by configfs could be easily backed up (right out of /etc), with nothing more powerful than a shell script, in 'non-binary' form to satisfy the ambient level of paranoia. Third, assuming the translation software is well implemented, it should be possible to merge in data sets which are in canonical /etc form into the database. This provides for easy initial conversion, mass updates and even recovery should the worst happen to the binary database. Last, I haven't heard many complaints about vipw as an administration tool; perhaps the same acceptance would be gained with, say, vihosts or vigroup. Granted, the total sum of work necessary to do this is arguably no less than a writable configfs. The difference is that each configuration file which requires this facility is implemented discretely, and only if really necessary. With a write-able configfs, it is pretty much all or nothing. I don't think many would really miss the privilege of hand editing resolve.conf, shells or host.conf, so why expect that the proverbial 'someone' should have to implement these in a write-able configfs? > So whatever we end up with has to be runnable in a > pretty 'minimal' environment... ;-) - i.e. the back end of a 1.44Mb fixit > disk... This is a tough requirement. The need to support extremely minimal environments is significant, if for no other reason than that it demonstrates a certain elegance to get a kernel with TCP/IP, PPP, FTP and sysinstall onto a diskette. The discussion has orbited around some sort of transaction engine (LDAP perhaps) and a session manager to control the database. General purpose transaction engines are prohibitively large. My assumption has been that the expectation is to have clients of system configuration data migrate to querying the database for needed information. This assumes the database is up. Supporting this on a 1.44Mb diskette sounds tough. The easy way out is to identify the programs which are necessary in a minimal environment and support continued /etc/* dependency for this subset. In this case /etc would be real (as opposed to configfs) on the floppy (or ram, or boot-rom, or...) and the system would bootstrap and run without the database. The question is, which stay in /etc and which evolve? Another way would be to roll our own (read-only?) database library, which, being implemented with smallness foremost in the mind of a very talented developer, would be acceptable in a minimal environment. The compromise is that it would have none of the expected benefits of the real thing. As I think about it, this may be workable; as long as the minimal subset of programs continues think its dealing with the full-blown database and the data is static. The actual data could be stored in a hand edit-able format for modification too. Hmm. Allen 'please forgive me' Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Wed Apr 22 07:08:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA17924 for freebsd-config-outgoing; Wed, 22 Apr 1998 07:08:42 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA17916 for ; Wed, 22 Apr 1998 14:08:39 GMT (envelope-from softweyr@xmission.com) Received: from slc254h.modem.xmission.com (xmission.com) [166.70.9.254] by mail.xmission.com with esmtp (Exim 1.82 #2) id 0yS0CV-0004DG-00; Wed, 22 Apr 1998 08:08:39 -0600 Message-ID: <353DFA79.A466D08@xmission.com> Date: Wed, 22 Apr 1998 08:11:05 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: allen campbell CC: config@FreeBSD.ORG Subject: Re: Config Databases References: <199804220731.BAA13255@const.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk allen campbell wrote: > I would like to share my thoughts on 'good export / import' here. > The possibility of a portal file system which would export the > various domains of the database as /etc/* files was mentioned. > Several people, including myself, thought this was an excellent > idea. At the same time, the ability to write to these pseudo-files > and cause database updates occur was also offered. I have since > formulated a few thoughts on this. One of the things that makes me nervous about much of this discussion is the ever-widening gap between the administration model on a stand-alone FreeBSD system vs. one included in a 'managed domain'. One of the unique benefits of using a read/write portal is the 'sameness' of the administration model. On a standalone system, administration is done by editing the files, which simply exist on the disk. In a domain member, administration is done by editing the files, which don't really exist on disk, but look like they do. No additional code has to be written to provide the distributed features to system administration tools, or to consumers of system administration information; all of the complexity *and differences* are moved into the portal. This is a GOOD THING. I realize this isn't necessarily the easiest way to accomplish the goals, but I just don't think adding yet another dependency on the network for every running FreeBSD system is a goal we should hold in high esteem. Client-server computing has its places, but being able to login to your computer *is not one of them.* The data needs to be replicated on the local disk in case of catastrophic network failure, so the users might still be able to accomplish *some* useful work. Like loggin in. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Wed Apr 22 23:29:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA14533 for freebsd-config-outgoing; Wed, 22 Apr 1998 23:29:29 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (fern13.verinet.com [199.45.181.77]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA14518 for ; Wed, 22 Apr 1998 23:29:25 -0700 (PDT) (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id AAA15142 for config@FreeBSD.ORG; Thu, 23 Apr 1998 00:30:18 -0600 (MDT) (envelope-from allenc) Date: Thu, 23 Apr 1998 00:30:18 -0600 (MDT) From: allen campbell Message-Id: <199804230630.AAA15142@const.> To: config@FreeBSD.ORG Subject: Re: Config Databases In-Reply-To: <353DFA79.A466D08@xmission.com> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > One of the unique benefits of using a read/write portal is the > 'sameness' of the administration model. On a stand-alone system, > administration is done by editing the files, which simply exist on > the disk. In a domain member, administration is done by editing > the files, which don't really exist on disk, but look like they do. > No additional code has to be written to provide the distributed > features to system administration tools, or to consumers of system > administration information; all of the complexity *and differences* > are moved into the portal. > > This is a GOOD THING. Files in a portal file system are expected to behave in a manner similar to 'real' files. I think this precludes the possibility of a writable configfs. This becomes obvious when you begin to consider the possible failure modes. Bob, the administrator, invokes vi on /etc/passwd to add an account. Bob is kind of new at this and he forgets to specify a login shell for this new account. By writing to /etc/passwd, Bob has implicitly invoked a 'portal process', because /etc/passwd is a file in our portal file-system. Now our portal process is expected to parse the buffer and put the result in our configuration database. Fortunately, the portal process in question was implemented very well and the login shell omission is noticed. Now what? What is the portal file system supposed to do with this? Being the rank amateur that I am, I have to consult write(2) to get an idea of what methods our portal process might try to convey its discovery. The return value I find which is the least distant from the notion of a ill-formated /etc/passwd file is [EIO] An I/O error occurred while reading from or writing to the file system. This is what would happen to vi when it attempted to write the buffer. Kinda vague no? If you expect to use canonical tools, like vi, against the portal file system, then that file system has to behave like a 'normal' file system. We can't just make up new error codes to suit the needs of parsing configuration files. Even if we could, an error code can not convey a specific line number, or a man page reference in an effort to help Bob get this done. Bob is left with a passwd file he cannot save. Step 2: send mail to HELP!@FreeBSD.ORG... I posed an alternative to this which you failed to address, even in criticism. From a root shell, type vipw. Lo! Your editing master.passwd. When you finish, the buffer is used to build the password database stored in /etc/pwd.db (see pwd_mkdb for the whole story.) Oh, and should you happen to be Bob that day, vipw won't let you save your work. Instead, vipw reports the problem to you and asks you to correct the problem (or abandon the attempt.) If Bob is the iconoclastic type, he may define EDITOR to specify what ever alternative editor he prefers. Bob gets the same benefit of data validation regardless. This model could be generalized to handle almost any format of configuration file. A read-only (portal file system) configfs would export files, which are then edited and parsed back into the database with a user space process like pwd_mkdb. As vipw has already proven, very little change is imposed on administrators. Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Thu Apr 23 00:48:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA23838 for freebsd-config-outgoing; Thu, 23 Apr 1998 00:48:01 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA23816 for ; Thu, 23 Apr 1998 00:47:58 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id AAA28587; Thu, 23 Apr 1998 00:47:42 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: allen campbell cc: config@FreeBSD.ORG Subject: Re: Config Databases In-reply-to: Your message of "Thu, 23 Apr 1998 00:30:18 MDT." <199804230630.AAA15142@const.> Date: Thu, 23 Apr 1998 00:47:41 -0700 Message-ID: <28583.893317661@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Now our portal process is expected to parse the buffer and put the > result in our configuration database. Fortunately, the portal > process in question was implemented very well and the login shell > omission is noticed. > > Now what? What is the portal file system supposed to do with this? Silently refuse the operation. Bob would be able to save the passwd file, but when he looked at it again he'd see it was as if he'd never touched it. Confusing? Sure, at least until people get the idea, but I think it's the only paradigm which makes sense. Your /etc is made of rubber - you hit it in the wrong place and it simply bounces back like nothing ever happened. :) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Thu Apr 23 00:53:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA24370 for freebsd-config-outgoing; Thu, 23 Apr 1998 00:53:37 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA24312 for ; Thu, 23 Apr 1998 00:53:31 -0700 (PDT) (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id LAA15352; Thu, 23 Apr 1998 11:50:00 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id KAA28409; Thu, 23 Apr 1998 10:12:23 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id JAA07301; Thu, 23 Apr 1998 09:51:59 +0200 (CEST) Message-ID: <19980423095159.61106@deepo.prosa.dk> Date: Thu, 23 Apr 1998 09:51:59 +0200 From: Philippe Regnauld To: "Jordan K. Hubbard" Cc: allen campbell , config@FreeBSD.ORG Subject: Re: Config Databases References: <199804230630.AAA15142@const.> <28583.893317661@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: <28583.893317661@time.cdrom.com>; from Jordan K. Hubbard on Thu, Apr 23, 1998 at 12:47:41AM -0700 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Jordan K. Hubbard writes: > > > > Now what? What is the portal file system supposed to do with this? > > Silently refuse the operation. Bob would be able to save the > passwd file, but when he looked at it again he'd see it was as > if he'd never touched it. Maybe bounce a message to the console ? Or a "configfs.log"... > Confusing? Sure, at least until people get the idea, but I think it's > the only paradigm which makes sense. Your /etc is made of rubber - > you hit it in the wrong place and it simply bounces back like nothing > ever happened. :) ... at least have _something_ else bounce back (call it quantum effect :-) -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Thu Apr 23 13:25:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA19905 for freebsd-config-outgoing; Thu, 23 Apr 1998 13:25:32 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA19896 for ; Thu, 23 Apr 1998 13:25:20 -0700 (PDT) (envelope-from softweyr@xmission.xmission.com) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.8/8.7.5) id OAA18834; Thu, 23 Apr 1998 14:24:44 -0600 (MDT) From: Wes Peters - Softweyr LLC Message-Id: <199804232024.OAA18834@xmission.xmission.com> Subject: Re: Config Databases To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 23 Apr 1998 14:24:43 -0600 (MDT) Cc: allen@xmission.xmission.com, campbell@xmission.xmission.com (Chris Campbell), , config@FreeBSD.ORG In-Reply-To: <28583.893317661@time.cdrom.com> from "Jordan K. Hubbard" at Apr 23, 98 00:47:41 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Allen Campbell asked: > > Now our portal process is expected to parse the buffer and put the > > result in our configuration database. Fortunately, the portal > > process in question was implemented very well and the login shell > > omission is noticed. > > > > Now what? What is the portal file system supposed to do with this? Jordan K. Hubbard replied: > Silently refuse the operation. Bob would be able to save the > passwd file, but when he looked at it again he'd see it was as > if he'd never touched it. Keep in mind that the configfs can return whatever error necessary; the man page reflects the implementation, not vice versa. We could even add new ones if needed. Some that also make sense to use include: EINVAL EROFS EDOM ERANGE ENAMETOOLONG ENOLCK EAUTH ENEEDAUTH -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Thu Apr 23 13:32:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20869 for freebsd-config-outgoing; Thu, 23 Apr 1998 13:32:29 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20864 for ; Thu, 23 Apr 1998 13:32:18 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id NAA01940; Thu, 23 Apr 1998 13:32:04 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Wes Peters - Softweyr LLC cc: allen@xmission.xmission.com, campbell@xmission.xmission.com (Chris Campbell), allenc@verinet.com, config@FreeBSD.ORG Subject: Re: Config Databases In-reply-to: Your message of "Thu, 23 Apr 1998 14:24:43 MDT." <199804232024.OAA18834@xmission.xmission.com> Date: Thu, 23 Apr 1998 13:32:04 -0700 Message-ID: <1937.893363524@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Keep in mind that the configfs can return whatever error necessary; I know, but deciding *which errors* to return could consume a lot of time. I really do think one would save a considerable amount of time and contraversy by simply implementing it as I suggested. Some errno returns *will* suggest themselves so obviously that there's no reason not to return them (ENOENT certainly being one :-), but I'd just shy completely away from the whole "I/O error" class and just write that off as something to grapple with (maybe, haha) in the 2nd version. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Thu Apr 23 13:45:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22580 for freebsd-config-outgoing; Thu, 23 Apr 1998 13:45:57 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22573 for ; Thu, 23 Apr 1998 13:45:51 -0700 (PDT) (envelope-from softweyr@xmission.xmission.com) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.8/8.7.5) id OAA22676; Thu, 23 Apr 1998 14:45:46 -0600 (MDT) From: Wes Peters - Softweyr LLC Message-Id: <199804232045.OAA22676@xmission.xmission.com> Subject: Re: Config Databases To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 23 Apr 1998 14:45:45 -0600 (MDT) Cc: config@FreeBSD.ORG In-Reply-To: <1937.893363524@time.cdrom.com> from "Jordan K. Hubbard" at Apr 23, 98 01:32:04 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > > > Keep in mind that the configfs can return whatever error necessary; > > I know, but deciding *which errors* to return could consume a lot of > time. I really do think one would save a considerable amount of time > and contraversy by simply implementing it as I suggested. Some errno > returns *will* suggest themselves so obviously that there's no reason > not to return them (ENOENT certainly being one :-), but I'd just shy > completely away from the whole "I/O error" class and just write that off > as something to grapple with (maybe, haha) in the 2nd version. I see what you're saying. ENOENT, EPERM, EROFS where they make sense, and ESCREWED (well, EIO) for everything else? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Thu Apr 23 14:04:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25250 for freebsd-config-outgoing; Thu, 23 Apr 1998 14:04:26 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25243 for ; Thu, 23 Apr 1998 14:04:15 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id OAA02200; Thu, 23 Apr 1998 14:04:01 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Wes Peters - Softweyr LLC cc: config@FreeBSD.ORG Subject: Re: Config Databases In-reply-to: Your message of "Thu, 23 Apr 1998 14:45:45 MDT." <199804232045.OAA22676@xmission.xmission.com> Date: Thu, 23 Apr 1998 14:04:01 -0700 Message-ID: <2195.893365441@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > I see what you're saying. ENOENT, EPERM, EROFS where they make sense, > and ESCREWED (well, EIO) for everything else? ;^) No, ENOTHING. As I said, the operations should just silently "succeed" in the cases where the user has attempted to do a bonehead file operation but not reflect the change. "Never check for an error condition you don't know how to handle." :-) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 00:09:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA10017 for freebsd-config-outgoing; Fri, 24 Apr 1998 00:09:06 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (willow24.verinet.com [199.45.181.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA10008 for ; Fri, 24 Apr 1998 00:08:56 -0700 (PDT) (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id BAA16897 for config@FreeBSD.ORG; Fri, 24 Apr 1998 01:10:08 -0600 (MDT) (envelope-from allenc) Date: Fri, 24 Apr 1998 01:10:08 -0600 (MDT) From: allen campbell Message-Id: <199804240710.BAA16897@const.> To: config@FreeBSD.ORG Subject: Re: Config Databases In-Reply-To: <2195.893365441@time.cdrom.com> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > No, ENOTHING. As I said, the operations should just silently > "succeed" in the cases where the user has attempted to do a bonehead > file operation but not reflect the change. "Never check for an error > condition you don't know how to handle." :-) I underestimated the appeal of a fully reflexive configuration file system. :) Perhaps I'm wrong, but I don't think we can do without a solid way to interactively report detected errors. I came up with a possible solution. Most configuration files support some form of comment. Why not use this facility to report inconsistencies? The result of writing a bogus /etc/passwd might look like; [ previous entries snipped ] # << The following errors have been detected: >> # << Missing login shell >> # << The following entry has been ignored >> # << See passwd(5) for further information >> foo:*:1003:1003:Foo Bar III:/home/foobar If you happen to catch something more subtle than a syntax error... [ previous entries snipped ] foo:*:1003:1003:foo:/home/foo:/bin/sh # << The following errors have been detected: >> # << Non-unique UID value >> # << The following entry has been ignored >> # << See passwd(5) for further information >> bar:*:1003:1004:bar:/home/bar:/bin/sh This could make configfs downright helpful. The ability of configfs to annotate configuration files could be used pro-actively... [ from somewhere in the equivalent of rc.conf ] # << WARNING, hostname remains unassigned. >> # << See hostname(1) for further information. >> hostname="myname.my.domain" The file system could have the ability to provide variable levels of annotation. Experienced users could turn off the noise (and turn it back on when they need help being experienced. :) The distribution default would naturally be verbose. This might lead to the portal file system becoming the primary interface for configuration. However, other configuration tools would be able to benefit from the same validation and error reporting. Assuming they consistently interact with configfs through a protocol or write to the portal files directly, the configuration file system becomes the final arbiter of configuration. I use /etc/passwd as a hypothetical example only. I understand there are larger implications to be considered with /etc/passwd. Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 00:34:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA14284 for freebsd-config-outgoing; Fri, 24 Apr 1998 00:34:48 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA14276 for ; Fri, 24 Apr 1998 00:34:37 -0700 (PDT) (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id LAA25805; Fri, 24 Apr 1998 11:31:12 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id JAA00158; Fri, 24 Apr 1998 09:53:36 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id JAA01197; Fri, 24 Apr 1998 09:33:00 +0200 (CEST) Message-ID: <19980424093259.13767@deepo.prosa.dk> Date: Fri, 24 Apr 1998 09:32:59 +0200 From: Philippe Regnauld To: allen campbell Cc: config@FreeBSD.ORG Subject: Re: Config Databases References: <2195.893365441@time.cdrom.com> <199804240710.BAA16897@const.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: <199804240710.BAA16897@const.>; from allen campbell on Fri, Apr 24, 1998 at 01:10:08AM -0600 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk allen campbell writes: > > Most configuration files support some form of comment. Why not > use this facility to report inconsistencies? > > The result of writing a bogus /etc/passwd might look like; [...] > This could make configfs downright helpful. The ability of configfs > to annotate configuration files could be used pro-actively... Hmm, I'm not (for what it's worth) really satisfied with either approach. So far: Jordan suggests that _nothing_ be returned when an error is encountered. -> silently drop the modification: problem: how is the user supposed to know he made a mistake ? You can't rely on the person to manually check after every mod. Allen suggests annotating the "file" (this is configfs) with the related errors. That means once again that the user should check manually. problem: a bit better, but the user still has to go and look In both cases, there is no direct feedback of user failure. Either I missed an episode, or that's a quite unusual way to do things -- and unlike anything else we have: Case 1: vi /etc/group && insert garbage -> something breaks, the user might/will notice -> in any case, he can track down and look in /etc/group and _see_ the mistakes Case 2: vipw && insert garbage -> feedback on what's wrong right away In the first suggestion (silently bouncing) means there's not even _trace_ of the mods, right ? Hmmm.. -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 00:42:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA14913 for freebsd-config-outgoing; Fri, 24 Apr 1998 00:42:44 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA14904 for ; Fri, 24 Apr 1998 00:42:39 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id AAA04439; Fri, 24 Apr 1998 00:42:30 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: allen campbell cc: config@FreeBSD.ORG Subject: Re: Config Databases In-reply-to: Your message of "Fri, 24 Apr 1998 01:10:08 MDT." <199804240710.BAA16897@const.> Date: Fri, 24 Apr 1998 00:42:29 -0700 Message-ID: <4436.893403749@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Most configuration files support some form of comment. Why not > use this facility to report inconsistencies? Can of worms. I'd leave it shut and just implement the darn thing already. :-) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 00:47:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA15747 for freebsd-config-outgoing; Fri, 24 Apr 1998 00:47:50 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA15700 for ; Fri, 24 Apr 1998 00:47:43 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id AAA04478; Fri, 24 Apr 1998 00:47:28 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Philippe Regnauld cc: allen campbell , config@FreeBSD.ORG Subject: Re: Config Databases In-reply-to: Your message of "Fri, 24 Apr 1998 09:32:59 +0200." <19980424093259.13767@deepo.prosa.dk> Date: Fri, 24 Apr 1998 00:47:27 -0700 Message-ID: <4474.893404047@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > problem: how is the user supposed to know he made a mistake ? You ca He'll know it pretty conclusively, I think, when the change he just made mysteriously has no effect whatsoever and doesn't show up in the file. :) > In the first suggestion (silently bouncing) means there's not even > _trace_ of the mods, right ? Hmmm.. Right. I'm not saying that this behavior is ideal, far from it, I'm simply saying that this is the lowest-impact approach and will require the least programming headache. Unless we're all just discussing this as an intellectual exercise, of course, and there's no intention of actually implementing it in which case by all means let's discuss all the errors one might pass back on close() in hopes that the application will even check the return value. :-) Succeeding silently and using secret knowledge of the file format to tack in comments also strikes me as a cute but ultimately untenable workaround, so I really do vote for the simpler approach. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 01:16:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA20094 for freebsd-config-outgoing; Fri, 24 Apr 1998 01:16:42 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA20089 for ; Fri, 24 Apr 1998 01:16:39 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.8.7/8.6.12) id IAA07962; Fri, 24 Apr 1998 08:16:35 GMT Message-ID: <19980424011635.26988@nuxi.com> Date: Fri, 24 Apr 1998 01:16:35 -0700 From: "David O'Brien" To: allen campbell Cc: config@FreeBSD.ORG Subject: Re: Config Databases Reply-To: obrien@NUXI.com References: <2195.893365441@time.cdrom.com> <199804240710.BAA16897@const.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199804240710.BAA16897@const.>; from allen campbell on Fri, Apr 24, 1998 at 01:10:08AM -0600 X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2.5-STABLE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Not directly related, but... > [ previous entries snipped ] > # << The following errors have been detected: >> > # << Missing login shell >> Not an error, defaults to /bin/sh > # << The following errors have been detected: >> > # << Non-unique UID value >> > # << The following entry has been ignored >> In my book, not an error. I have two accounts for myself with the same UID -- my usual one with a fancy shell, and a backup account with /bin/sh incase something happened to the NFS mounted /usr/local So this may beg the question, if there needs to be the ability to express a policy to determine what constitutes an error. -- -- David (obrien@NUXI.ucdavis.edu -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 02:51:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA06851 for freebsd-config-outgoing; Fri, 24 Apr 1998 02:51:06 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from huset.math.ntnu.no (huset.math.ntnu.no [129.241.211.212]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA06845 for ; Fri, 24 Apr 1998 02:51:03 -0700 (PDT) (envelope-from arnej@stud.math.ntnu.no) Message-Id: <199804240951.CAA06845@hub.freebsd.org> Received: (qmail 20406 invoked from network); 24 Apr 1998 09:50:58 -0000 Received: from huset.math.ntnu.no (HELO stud.math.ntnu.no) (129.241.211.212) by huset.math.ntnu.no with SMTP; 24 Apr 1998 09:50:58 -0000 To: jkh@time.cdrom.com Cc: regnauld@deepo.prosa.dk, allenc@verinet.com, config@FreeBSD.ORG Subject: Re: Config Databases In-Reply-To: Your message of "Fri, 24 Apr 1998 00:47:27 -0700" References: <4474.893404047@time.cdrom.com> X-Mailer: Mew version 1.54 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 24 Apr 1998 11:50:58 +0200 From: Arne Henrik Juul Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Jordan K. Hubbard writes: > > > problem: how is the user supposed to know he made a mistake ? You ca > > He'll know it pretty conclusively, I think, when the change he just > made mysteriously has no effect whatsoever and doesn't show up in the > file. :) Speaking as a long-term system administrator, this is the most stupid suggestion I've ever heard, and using a thing like this would make me wish for Windows. (hmmm... that's about the max-value on my flame- thrower I think :-) > Succeeding silently and using secret knowledge of the file format to > tack in comments also strikes me as a cute but ultimately untenable > workaround, so I really do vote for the simpler approach. This *might* be OK. If you want to do a "simpler approach" I'd say it's better to make the configfs files read-only until there is something in place that can report errors in a sensible way. - Arne H. J. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 03:05:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA10727 for freebsd-config-outgoing; Fri, 24 Apr 1998 03:05:16 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA10721 for ; Fri, 24 Apr 1998 03:05:13 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id DAA23463; Fri, 24 Apr 1998 03:04:17 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Arne Henrik Juul cc: regnauld@deepo.prosa.dk, allenc@verinet.com, config@FreeBSD.ORG Subject: Re: Config Databases In-reply-to: Your message of "Fri, 24 Apr 1998 11:50:58 +0200." <199804240951.CAA06845@hub.freebsd.org> Date: Fri, 24 Apr 1998 03:04:17 -0700 Message-ID: <23459.893412257@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Speaking as a long-term system administrator, this is the most stupid > suggestion I've ever heard, and using a thing like this would make me If you as a long-term system administrator do stupid things like edit /etc/passwd directly, you deserve to be shot anyway. :-) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 06:43:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA05220 for freebsd-config-outgoing; Fri, 24 Apr 1998 06:43:58 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from murkwood.gaffaneys.com (dialup10.gaffaneys.com [208.155.161.60]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA05211 for ; Fri, 24 Apr 1998 06:43:47 -0700 (PDT) (envelope-from zach@gaffaneys.com) Received: (from zach@localhost) by murkwood.gaffaneys.com (8.8.8/8.8.8) id IAA17174; Fri, 24 Apr 1998 08:24:11 -0500 (CDT) (envelope-from zach) Message-ID: <19980424082411.52198@gaffaneys.com> Date: Fri, 24 Apr 1998 08:24:11 -0500 From: Zach Heilig To: "Jordan K. Hubbard" , Philippe Regnauld Cc: allen campbell , config@FreeBSD.ORG Subject: Re: Config Databases References: <19980424093259.13767@deepo.prosa.dk> <4474.893404047@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <4474.893404047@time.cdrom.com>; from Jordan K. Hubbard on Fri, Apr 24, 1998 at 12:47:27AM -0700 Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk On Fri, Apr 24, 1998 at 12:47:27AM -0700, Jordan K. Hubbard wrote: > > problem: how is the user supposed to know he made a mistake ? > He'll know it pretty conclusively, I think, when the change he just > made mysteriously has no effect whatsoever and doesn't show up in the > file. :) Bah! the user should be told somehow, I vote for using /var/run/log :-) -- Zach Heilig -- zach@gaffaneys.com Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 10:07:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA04420 for freebsd-config-outgoing; Fri, 24 Apr 1998 10:07:50 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA04332 for ; Fri, 24 Apr 1998 10:07:31 -0700 (PDT) (envelope-from softweyr@xmission.xmission.com) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.8/8.7.5) id LAA04969; Fri, 24 Apr 1998 11:07:25 -0600 (MDT) From: Wes Peters - Softweyr LLC Message-Id: <199804241707.LAA04969@xmission.xmission.com> Subject: Re: Config Databases To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 24 Apr 1998 11:07:25 -0600 (MDT) Cc: config@FreeBSD.ORG In-Reply-To: <4474.893404047@time.cdrom.com> from "Jordan K. Hubbard" at Apr 24, 98 00:47:27 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Right. I'm not saying that this behavior is ideal, far from it, I'm > simply saying that this is the lowest-impact approach and will require > the least programming headache. And, please note, it *is* consistent with current practice. If you enter a bogus password entry with vipw, it gets put in the file, but the user *still* won't be able to login. > Unless we're all just discussing this > as an intellectual exercise, of course, and there's no intention of > actually implementing it in which case by all means let's discuss all > the errors one might pass back on close() in hopes that the > application will even check the return value. :-) Well, vi will at least. That saves us in the 'viconfig' case. ;^) The only granularity you really *need* is 'OK, it worked' vs. 'ERROR, something was wrong.' > Succeeding silently and using secret knowledge of the file format to > tack in comments also strikes me as a cute but ultimately untenable > workaround, so I really do vote for the simpler approach. The 'odm database' in AIX uses the approach, and it is helpful, but it costs them a lot of programmer time to develop and maintain their import programs. Bleh. Jordan's right (as usual): get it working, then embellish it later. I suggest starting off with one simple database, something simple like /etc/services, and getting IT working, then adding other databases. This has the advantage of being able to dole out addition of various databases to a fairly wide range of people once the initial framework is in place. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 16:51:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA28840 for freebsd-config-outgoing; Fri, 24 Apr 1998 16:51:08 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (willow18.verinet.com [199.45.181.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA28823 for ; Fri, 24 Apr 1998 16:50:59 -0700 (PDT) (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id RAA18027 for config@FreeBSD.ORG; Fri, 24 Apr 1998 17:52:24 -0600 (MDT) (envelope-from allenc) Date: Fri, 24 Apr 1998 17:52:24 -0600 (MDT) From: allen campbell Message-Id: <199804242352.RAA18027@const.> To: config@FreeBSD.ORG Subject: Re: Config Databases In-Reply-To: <19980424093259.13767@deepo.prosa.dk> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Case 1: vi /etc/group && insert garbage -> something breaks, the user > might/will notice -> in any case, he can track down and look in > /etc/group and _see_ the mistakes > > Case 2: vipw && insert garbage -> feedback on what's wrong right away > > In the first suggestion (silently bouncing) means there's not even > _trace_ of the mods, right ? Hmmm.. The overwhelming consensus is to support a writable configfs. I agree with you but because of the results of the feedback, I am going along with the writable configfs, provided we can find an acceptable method of reporting errors. Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 16:57:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA29732 for freebsd-config-outgoing; Fri, 24 Apr 1998 16:57:25 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (willow18.verinet.com [199.45.181.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA29721 for ; Fri, 24 Apr 1998 16:57:20 -0700 (PDT) (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id RAA18050 for config@FreeBSD.ORG; Fri, 24 Apr 1998 17:58:46 -0600 (MDT) (envelope-from allenc) Date: Fri, 24 Apr 1998 17:58:46 -0600 (MDT) From: allen campbell Message-Id: <199804242358.RAA18050@const.> To: config@FreeBSD.ORG Subject: Re: Config Databases In-Reply-To: <4436.893403749@time.cdrom.com> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > > Most configuration files support some form of comment. Why not > > use this facility to report inconsistencies? > > Can of worms. I'd leave it shut and just implement the darn thing > already. :-) Why the impatience? A few good decisions now will save a lot of time. Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Fri Apr 24 17:32:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08277 for freebsd-config-outgoing; Fri, 24 Apr 1998 17:32:03 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08221 for ; Fri, 24 Apr 1998 17:31:52 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id RAA26435; Fri, 24 Apr 1998 17:31:44 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: allen campbell cc: config@FreeBSD.ORG Subject: Re: Config Databases In-reply-to: Your message of "Fri, 24 Apr 1998 17:58:46 MDT." <199804242358.RAA18050@const.> Date: Fri, 24 Apr 1998 17:31:44 -0700 Message-ID: <26431.893464304@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Why the impatience? A few good decisions now will save a lot of time. Momentum. If you guys don't make substantial progress on this in the next 3 months or so, the chances of success become vanishingly small. I've been here before on more than one occasion, and if I had to bet $100 on this project's success then I'd bet against you and feel fairly secure of my chances of collecting on that bet. :-) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sat Apr 25 01:33:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA26870 for freebsd-config-outgoing; Sat, 25 Apr 1998 01:33:48 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (willow21.verinet.com [199.45.181.53]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA26845 for ; Sat, 25 Apr 1998 01:33:43 -0700 (PDT) (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id CAA19174 for config@FreeBSD.ORG; Sat, 25 Apr 1998 02:35:16 -0600 (MDT) (envelope-from allenc) Date: Sat, 25 Apr 1998 02:35:16 -0600 (MDT) From: allen campbell Message-Id: <199804250835.CAA19174@const.> To: config@FreeBSD.ORG Subject: Re: Config Databases In-Reply-To: <4474.893404047@time.cdrom.com> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > > problem: how is the user supposed to know he made a mistake ? You ca > > He'll know it pretty conclusively, I think, when the change he just > made mysteriously has no effect whatsoever and doesn't show up in the > file. :) The operative word there is 'mysteriously'. Jordan, this is dubious. First, as a result of a simple typo you get to lose your work (assuming you are not using merely a working copy.) Second, you are given no clue as to why. Lets call it Pavlovfs :) An analogy might be to use a compiler that reverts your source back to its pre-mod state and reports nothing. Are you suggesting this as a short term condition to speed development, implying something better would eventually be supported? > > In the first suggestion (silently bouncing) means there's not even > > _trace_ of the mods, right ? Hmmm.. > > Right. I'm not saying that this behavior is ideal, far from it, I'm > simply saying that this is the lowest-impact approach and will require > the least programming headache. In the main, the parser code already exists inside the programs which read the existing configuration files. Where one of these modules detects an error, it's not difficult to elaborate a bit and cause a message to be output. If a simple method to accumulate and output these messages is provided, I don't think its asking much to support it. BTW, there is no reason to delay an implementation as a result of adopting a particular feedback method. If the early versions of any particular parser contains no error reporting at all, so be it. > as an intellectual exercise, of course, and there's no intention of > actually implementing it in which case by all means let's discuss all > the errors one might pass back on close() in hopes that the > application will even check the return value. :-) > > Succeeding silently and using secret knowledge of the file format to > tack in comments also strikes me as a cute but ultimately untenable > workaround, so I really do vote for the simpler approach. If the portal file system is responsible for generating these files directly from the database, it's hard to argue that it shouldn't have complete knowledge of the file format. The 'cute' point is taken. Automatically annotating a file with comments is hard to generalize and could prove impractical given very large data sets. Please consider another alternative; Configfs could redirect whatever error messages are generated by the parser to a portal file which parallels the target file. A mock session... $cd /etc $vi syslog.conf [ .. A mistake is made in a facility name .. ] $cat syslog.conf.err * * syslog.conf.err * * Error on line 4. * Invalid facility. * * Errors detected in syslog.conf. * See syslog.conf(5) for help. * $vi syslog.conf [ .. The mistake is corrected .. ] $cat *.err cat: *.err: No such file or directory $ No comment hacks here and we use the blessings of the portal file system to report the errors. Not checking the corresponding *.err file is pilot error. The *.err file persists until the problem is resolved. Again, comprehensive error detection and reporting does not need to be a prerequisite to actual progress. Just that a solid method exists within configfs is enough. Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sat Apr 25 01:45:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA27729 for freebsd-config-outgoing; Sat, 25 Apr 1998 01:45:42 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA27721 for ; Sat, 25 Apr 1998 01:45:36 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id BAA17665; Sat, 25 Apr 1998 01:45:32 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: allen campbell cc: config@FreeBSD.ORG Subject: Re: Config Databases In-reply-to: Your message of "Sat, 25 Apr 1998 02:35:16 MDT." <199804250835.CAA19174@const.> Date: Sat, 25 Apr 1998 01:45:31 -0700 Message-ID: <17661.893493931@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Jordan, this is dubious. First, as a result of a simple typo you > get to lose your work (assuming you are not using merely a working > copy.) Second, you are given no clue as to why. Lets call it Again, only if you edit the *wrong* copy. In fact, why are we even arguing about mis-editing /etc/passwd? It should be read-only! :-) As to the other files you might screw up the formatting of, I would propose that rather than leave these nasty little .err files around (one is reminded of core dumps come back to haunt in another even more horrible incarnation :-) you simply log the messages to syslog. Then I can use syslog.conf to more flexibly route those messages to another host or have them chatter on people's consoles or _whatever_ it is I want to do with them. But this conversation has veered off at an undesirable tangent - we didn't start out to discuss what kinds of comments might be left in a file or how one might log failures, that's really a gravy decision anyway, what we started off discussing was what *errors would be returned* by open/close/read/write on failures that were really "misconfiguration errors." That's when I started arguing for simply returning a normal status and leave the errno setting to truly obvious/fatal I/O errors, not trying to hand back to vi a confusing errno just because a field was mis-entered. That's the can of worms we've already discussed. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sat Apr 25 01:48:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA28027 for freebsd-config-outgoing; Sat, 25 Apr 1998 01:48:04 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (willow21.verinet.com [199.45.181.53]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA27963 for ; Sat, 25 Apr 1998 01:47:58 -0700 (PDT) (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id CAA19253 for config@FreeBSD.ORG; Sat, 25 Apr 1998 02:49:31 -0600 (MDT) (envelope-from allenc) Date: Sat, 25 Apr 1998 02:49:31 -0600 (MDT) From: allen campbell Message-Id: <199804250849.CAA19253@const.> To: config@FreeBSD.ORG Subject: Re: Config Databases In-Reply-To: <19980424011635.26988@nuxi.com> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > > Not directly related, but... > > > [ previous entries snipped ] > > # << The following errors have been detected: >> > > # << Missing login shell >> > > Not an error, defaults to /bin/sh > > > # << The following errors have been detected: >> > > # << Non-unique UID value >> > > # << The following entry has been ignored >> > > In my book, not an error. > I have two accounts for myself with the same UID -- my usual one with a > fancy shell, and a backup account with /bin/sh incase something happened > to the NFS mounted /usr/local > > So this may beg the question, if there needs to be the ability to express > a policy to determine what constitutes an error. Bad examples perhaps. The missing shell might constitute a warning, which could be accommodated also. Are you sure about that default to /bin/sh? The code from getpwent.c looks like if ((s = strsep(&result, ":")) == NULL) return 0; /* shell */ if(!(pw->pw_fields & _PWF_SHELL)) { pw->pw_shell = s; pw->pw_fields |= _PWF_SHELL; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sat Apr 25 13:39:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13378 for freebsd-config-outgoing; Sat, 25 Apr 1998 13:39:29 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13367 for ; Sat, 25 Apr 1998 13:39:23 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id UAA01795 for ; Sat, 25 Apr 1998 20:39:16 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA19607; Sat, 25 Apr 1998 22:39:13 +0200 (MET DST) Message-ID: <19980425223913.09596@follo.net> Date: Sat, 25 Apr 1998 22:39:13 +0200 From: Eivind Eklund To: config@FreeBSD.ORG Subject: OSD - should this be added to pkg_*? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk Another attempt at an open standard for packaging, this time to record dependencies and what to run on which OS. http://www.microsoft.com/standards/osd/osdintro.htm The actual spec is available as a link of the above URL, and at http://www.w3.org/TR/NOTE-OSD.html It looks like it might be useful, and along with Sun's META=INF specification, it cover a large part of what we need in the packaing system. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sat Apr 25 14:57:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24438 for freebsd-config-outgoing; Sat, 25 Apr 1998 14:57:27 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24018 for ; Sat, 25 Apr 1998 14:56:18 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.8.7/8.6.12) id VAA17912; Sat, 25 Apr 1998 21:56:12 GMT Message-ID: <19980425145611.39068@nuxi.com> Date: Sat, 25 Apr 1998 14:56:11 -0700 From: "David O'Brien" To: allen campbell Cc: config@FreeBSD.ORG Subject: Re: Config Databases Reply-To: obrien@NUXI.com References: <19980424011635.26988@nuxi.com> <199804250849.CAA19253@const.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199804250849.CAA19253@const.>; from allen campbell on Sat, Apr 25, 1998 at 02:49:31AM -0600 X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2.5-STABLE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Are you sure about that default to /bin/sh? The code from getpwent.c looks > like from login.c: if ((pwd = getpwnam(username)) != NULL) ..snip.. if (*pwd->pw_shell == '\0') pwd->pw_shell = _PATH_BSHELL; -- -- David (obrien@NUXI.ucdavis.edu -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sat Apr 25 19:58:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA29585 for freebsd-config-outgoing; Sat, 25 Apr 1998 19:58:52 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from const. (willow6.verinet.com [199.45.181.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA29473 for ; Sat, 25 Apr 1998 19:57:41 -0700 (PDT) (envelope-from allenc@verinet.com) Received: (from allenc@localhost) by const. (8.8.8/8.8.8) id UAA23369 for config@FreeBSD.ORG; Sat, 25 Apr 1998 20:59:29 -0600 (MDT) (envelope-from allenc) Date: Sat, 25 Apr 1998 20:59:29 -0600 (MDT) From: allen campbell Message-Id: <199804260259.UAA23369@const.> To: config@FreeBSD.ORG Subject: Re: Config Databases In-Reply-To: <17661.893493931@time.cdrom.com> Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > As to the other files you might screw up the formatting of, I would > propose that rather than leave these nasty little .err files around > (one is reminded of core dumps come back to haunt in another even more > horrible incarnation :-) you simply log the messages to syslog. Then > I can use syslog.conf to more flexibly route those messages to another > host or have them chatter on people's consoles or _whatever_ it is > I want to do with them. This sounds right. Good feedback, regardless of the mechanism, is what matters. > But this conversation has veered off at an undesirable tangent - we > didn't start out to discuss what kinds of comments might be left in a > file or how one might log failures, that's really a gravy decision > anyway, what we started off discussing was what *errors would be > returned* by open/close/read/write on failures that were really > "misconfiguration errors." That's when I started arguing for simply > returning a normal status and leave the errno setting to truly > obvious/fatal I/O errors, not trying to hand back to vi a confusing > errno just because a field was mis-entered. That's the can of worms > we've already discussed. Extending errno became a part of this as an example of a wrong way to handle configfs 'misconfiguration errors.' I would never advocate doing this. My goal has been to find the right way. Leave to errno what is errno's :) Use syslog for configfs gripes. I'm happy with that. Allen Campbell allenc@verinet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message From owner-freebsd-config Sat Apr 25 20:38:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA05802 for freebsd-config-outgoing; Sat, 25 Apr 1998 20:38:19 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles322.castles.com [208.214.167.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA05783 for ; Sat, 25 Apr 1998 20:38:06 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id UAA01885; Sat, 25 Apr 1998 20:35:14 -0700 (PDT) Message-Id: <199804260335.UAA01885@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Eivind Eklund cc: config@FreeBSD.ORG Subject: Re: OSD - should this be added to pkg_*? In-reply-to: Your message of "Sat, 25 Apr 1998 22:39:13 +0200." <19980425223913.09596@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 20:35:12 -0700 From: Mike Smith Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Another attempt at an open standard for packaging, this time to record > dependencies and what to run on which OS. > > http://www.microsoft.com/standards/osd/osdintro.htm > > The actual spec is available as a link of the above URL, and at > > http://www.w3.org/TR/NOTE-OSD.html My biggest beef with this is that it requires all of the intelligence be in either the OSD consumer (browser), or an unconnected helper application. There appears to be no way that you can say: - on this OS version I depend on A, B and C - but on that OS version, I need A, C, D and E for example. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message