Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.unix.wizards Subject: Re: syslog + chroot + ftpd Message-ID: <11477:Jul3018:50:4290@kramden.acf.nyu.edu> Date: 30 Jul 90 18:50:42 GMT References: <1990Jul29.202447.11548@athena.mit.edu> Distribution: usa Organization: IR Lines: 44 In article <1990Jul29.202447.11548@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes [ trimmed & reordered ]: > In article <29159:Jul2820:23:5290@kramden.acf.nyu.edu>, > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > |> syslog's poor model has ftp writing to a UNIX-domain socket in the > |> filesystem. Naturally, ftp can't find the file after it chroots. Try > |> hardlinking in a new /dev/log (I think) below ftp's home directory. > Dan's first suggested solution will work for the special case of > ftpd's chroot() for anonymous ftp, but will not work for the general > case of other programs which do a chroot(). But it is the only solution for someone who doesn't want to muck with his libraries, or for someone without source code, or for someone who doesn't want to spend half an hour working bugs out of new BSD stuff. In other words, theory is nice, but I think Luis wanted practice. > |> If error messages were piped out stderr to an error-handling program, > |> these problems would never happen. > Dan's second suggested solution is, as is somewhat usual for Dan :-), > a condemnation of a particular feature of Unix simply because he > believes that it's "the wrong way to do things." Whether or not said > condemnation is correct, it holds little weight in my mind when > presented as an unsupported assertion. Say what? I believe that good old stderr is a much better model than syslog(), and I supported my assertion by pointing out that it would solve problems like this. > In any case, I disagree with it, > and think that the syslog system is useful in ways that "an > error-handling program" on stderr would not be. Now you're making unsupported assertions. In what conceivable way can syslog() do better than stderr? We could settle on some conventions for standard error message formats, then make programs to interpret them in different ways. This is obviously much more general and flexible than syslog: you can change what's done with a program's errors simply by editing a command line. You don't have to futz with syslogd, edit any configuration files, stick new 'n' important special files into your system, or conform to the facility-level-file model of error handling. In the future we'll get backward compatibility trivially, rather than by leaving obsolete daemons, /dev/log, and similar clutter around. ---Dan