Date: Thu, 4 Jul 1996 12:53:36 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joelh@gnu.ai.mit.edu Cc: terry@lambert.org, gpalmer@FreeBSD.ORG, jmb@freefall.freebsd.org, tom@sdf.com, jgreco@brasil.moneng.mei.com, root@friday.keanesea.com, hackers@FreeBSD.ORG Subject: Re: What is the best way to setup a drive Message-ID: <199607041953.MAA13427@phaeton.artisoft.com> In-Reply-To: <199607040559.BAA14799@kropotkin.gnu.ai.mit.edu> from "Joel Ray Holveck" at Jul 4, 96 01:59:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I had been responding to the symlink idea that jmb proposed. > > Is there any problem with symlinking /etc/passwd to something on a r/w > filesystem instead of dealing with NIS, to deal with pre-yp programs > that don't think to call getpwent()? I suppose that the /etc/ptmp > lockfile would have to be dealt with accordingly in that event, but > there should be ways to handle that. I don't think there is a problem with symlinking /etc/passwd; in theory, it's not in use until after the mounts are done. The lock wants to go into /var/spool/lock; since it's a mounted FS, it means that the directory structure should either be skeletonized then union mounted, so that the lock file can be created before the mount has taken place. For that matter, one can replace the passwd file with a union mount (I wonder if *this* was how the breakin was done?). > Where are the perms for /dev/tty* stored? Ideally, in the kernel. It's kind of bogus to make the distinction that rc.serial does to avoid what every other UNIX system in existance uses (except Microport or a SunOS machine with bad serial flags settings), the partial open hack. The idea is that an open with O_NDELAY allows an open without DCD present, and communication with the port. Since the O_NDELAY also also sets non-blocking I/O, the correction is to reopen the port *without* the O_NDELAY flag. Since a first open exists, the second open is not blocked pending DCD, even though DCD is not present, and a first open would block... that is, the second open succeeds, since the device is already "partially open". The idea that devices should be templated is a correct one. But using rc.serial to set the template values is incorrect. The template values can be set to the industry standard defaults, pending the DCD coming high. It is possible for programs (like getty) to set the defaults by using the now-open device. The magic is in then waiting for DCD. The *best* way to do this is to reset the partially open flag by specifying a blocking open (to be implemented by ioctl()) if in fact things need to be set. About the only thing that *does* need to be set in this category is the RTS/CTS out of band flow control. Note that an open prior to DCD being raised must assert outbound CTS/RTS and ingore-as-if-present inbound CTS/RTS. This allows use of a NULL-modem cable to bidirectionally permit logins over serial connections between directly connected machines, *without* falling into the "getty respawing too rapidly" trap from the getty's talking to each other. In point of fact, getty is supposed o override all port settings anyway with the gettytab defaults; this is traditional behaviour for support of SLIP or PPP as line disciplines. For mgetty, there was already a long discussion, the gist of which is that yet another open flag is necessary, to allow the open to remain incomplete pending a "ring indicate" signal. Ideally, you want this on the RS232 RI input, but could substitute one of the other signals in a pinch. This removes all of the lock/timer crap necessary for use of an mgetty port for outbound connections, as necessary (for instance, a UUCP mail or netnews relay site). This leaves the /etc/ttys and the /etc/gettytab, which are permitted to be symbolic links, since they will not be referenced until the RC file has completed the mount of /var. > > What's left is /etc/fstab (dealt with by mount changes, which > > aren't the same thing as FS changes), /etc/rc* (bogus) and > > /etc/sysconfig (also bogus). > > Hmmm... We may also want to change paths.h (and > src/sbin/nologin/nologin.5; why is it in that directory instead of > shutdown or login?) to take care of /etc/nologin, although shutdown > will work fine without changing it. (Just be sure to remove it > manually your first attempt to boot with / r/o!) Yes. There are a number of things, like the password lock file, that could be handled by lstat() to read the link target and pointing there instead. The password lock file could then always exist in /etc, without disrupting the vipw, etc.. This is a less elegant soloution than simply moving the target elsewhere and fixing the software (which is BSD software, after all). > Should the comment from /etc/rc concern us?: "root must be read/write > both for NFS diskless and for VFS LKMs before proceeding any further." The NFS diskless issue is an obvious one, and can be resolved through ordering. It is my firm opinion that system configuration data should be *data*, not procedurally encoded. I would desperately like to see a /etc/rc/... directory; I would prefer run levels, but could live with a single directory for third party startup insertions. Along with that, one would expect a /var/rc/... directory, to be mixed in. Run levels would allow "minimal system" setup before proceeding to a run level which should reference /var. For instance, "run level 1" would get /var and everything else mounted before proceeding to startups requiring a mounted /var. All third party startup script installation would go into /var, freeing us from the need to change /etc for local differences in function. This is slightly different from the SYSV interpretation of "run level", which more closes resembles "run states". I can choose to go from one state to another, and all necessary state transitions will take place automatically. This is the ideal; in reality, we probably won't be allowed to murder /etc/rc* in its sleep. The next best thing would be to have it call an rc on /var after the mounts have occurred. The runtime changes shiuld still go on /var, an the /etc directory can remain unchanged. > > I really don't see where the problem is: throw out your > > bogositieis and fix the rest to comply with the design documents, > > and the problems all fade away. > > Who said there's a problem? I can't fix the programs at the current > time (no net connection on my test machine, forgot to pay the phone > bill), so I'm just pointing 'em out. 8-). > I'm new at this; what design documents are you referring to? For the FS, the Heidemann thesis. For BSD in general, the 4.4 Daemon book. There's actually a *lot* of reference material out there that has already been designated "design document". I'd like to see some additional design documents "ratified", or for the VM and associated work, written. Hell, there's some things I ought to document. 8-). That's a different battle, for another time. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607041953.MAA13427>