From owner-freebsd-hackers Sun Jan 12 05:39:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA27468 for hackers-outgoing; Sun, 12 Jan 1997 05:39:56 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA27463 for ; Sun, 12 Jan 1997 05:39:51 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.4/8.8.4) id LAA22147; Sun, 12 Jan 1997 11:38:55 +1100 (EST) Message-ID: Date: Sun, 12 Jan 1997 00:38:53 +0000 From: davidn@unique.usn.blaze.net.au (David Nugent) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: hackers@freebsd.org Subject: Re: DEVFS permissions &c. References: <16902.853042470@time.cdrom.com> X-Mailer: Mutt 0.56 Mime-Version: 1.0 In-Reply-To: ; from J Wunsch on Jan 12, 1997 11:20:12 +0100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch writes: > > Hmmm. Actually, ignore what I said earlier about group games - I > > agree with Joerg. :-) > > Although i should add that this is currently _not_ the case! I.e., > nobody wrote that ``permissions & persistancy'' module for rc(8) yet. > > I've exchanged a couple of thoughts with Bruce about it. Maybe we > could teach mtree(8) to help in this step. Yes, that would certainly be the way to do it. > Btw., a system shutdown script would come handy for this. Certainly. > What are the current ideas of a SysV init? :-) Shoot first and ask questions later? :-) Seriously, I've used sysv for many years, and grew to quickly despise the sysv approach. It does have some good sides, but, for example, Sun's tree of symlinks to init/shutdown scripts is definitely an overkill. It is cumbersome and difficult to manage, in spite of claims to the contrary. It makes it easier to manage from the admin scripts (to create/add scripts to startup/shutdown lists), but how many serious admins use those, trust them enough and remain sane for any period of time? This use of symlinks is abuse of the filesystem, pure and simple. KISS works better. Any /etc/rc.shutdown has /etc/sysconfig as a resource and should use it if relevent. And please - PLEASE - no "runlevels"! > Well, at least we could teach > our init to run something like /etc/rc.shutdown or such, which can do > all the dirty work. Init should probably impose a timeout for this > script (in case it hangs), how to configure this? A sysctl variable? > For normal machines (i.e., not news servers or other machines that > require mucho work at shutdown time), a grace period of 10 seconds > should suffice. Make it configurable (sysctl var?), but 10 seconds would seem like a reasonable default on most systems. I've found that if a news server, for example, is particularly busy, it can take up to a minute for ctlinnd shutdown to complete. A shutdown 'fastboot' option to bypass the shutdown script might also be useful. Of course, the 10 seconds wait is a moot point if the script returns earlier... Naturally, this brings ports in, with /usr/local/etc/rc.d scripts again, but you knew that. :-) > Why i'm bringing this into the game here? It would be the ideal spot > to dump out the state of DEVFS into a file. Yes. If it is made flexible enough, the admin can make a choice as to whether the permissions/ownership is static or persistent. /etc/sysconfig: # File from which devfs is initialised and set up devfs_init=/etc/mtree/BSD.devfs # File where devfs permissions are saved. Leave blank # if you want it to be the same as ${devfs_init}, which # causes permissions and ownerships to be persistant # between reboots. "NO" prevents them being saved at all. devfs_save= Perhaps the *existance* of an /etc/rc.shutdown will be enough to trigger it. Even on a freshly installed system, it wouldn't do much harm to run an empty script (although I can think of a couple of things to put there already :-)). Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/