From owner-freebsd-hackers Mon Apr 20 09:23:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA28855 for freebsd-hackers-outgoing; Mon, 20 Apr 1998 09:23:11 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA28765 for ; Mon, 20 Apr 1998 16:22:47 GMT (envelope-from dhw@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id JAA19584 for ; Mon, 20 Apr 1998 09:22:15 -0700 (PDT) Received: from pau-amma.whistle.com(207.76.205.64) by whistle.com via smap (V1.3) id sma019580; Mon Apr 20 09:21:58 1998 Received: (from dhw@localhost) by pau-amma.whistle.com (8.8.7/8.8.7) id JAA22948 for hackers@FreeBSD.ORG; Mon, 20 Apr 1998 09:21:58 -0700 (PDT) (envelope-from dhw) Date: Mon, 20 Apr 1998 09:21:58 -0700 (PDT) From: David Wolfskill Message-Id: <199804201621.JAA22948@pau-amma.whistle.com> To: hackers@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From: sfarrell+lists@farrell.org >Date: 17 Apr 1998 18:30:44 -0500 >Can't some kind of duality be established that gets the best of both >worlds? Use nsswitch.conf file that call tell it to e.g., first look >in the database and then in files for all information. Additionally, >some provision is made for the new system to auto-generate required >files in /etc? This sounds as if it would be a bit messy to implement... but as a systems administrator (who administers different kinds of systems), I would certainly prefer something like this to being forced to use something unique to FreeBSD (for either changing things or finding out how an existing system I've never seen before is configured so I can put out a fire...). >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. So vi /etc/rc.conf, >e.g., would just work, even though you'd actually be read/writing >directly to the database (a little like vipw, but with more magic). >Similarly this mechanism would maintain a backup of /etc in files as >mentioned in the previous paragraph. Actually, there's some functionality I very much miss with vipw (that I have with my updates of, say the "group" file on the NIS master): Tracking changes with RCS. I routinely use RCS to track changes to all kinds of things (except passwd; it's subject to various changes that I don't initite, such as folks changing their passwords), and I find it a useful bit of documentation. On the other hand, I understand how that might be less-well-received by some folks.... :-) david -- David Wolfskill dhw@whistle.com (650) 577-7158 pager: (650) 401-0168 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message