Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!eagle.wesleyan.edu!hdtodd
From: hdtodd@eagle.wesleyan.edu
Newsgroups: comp.sys.apollo
Subject: Re: lpr/lpd problems (revisited)
Message-ID: <1991Mar8.044653.39903@eagle.wesleyan.edu>
Date: 8 Mar 91 09:46:53 GMT
References: <1991Mar3.135954.39621@eagle.wesleyan.edu> <1991Mar6.213032.39820@eagle.wesleyan.edu> <38900@netnews.upenn.edu>
Organization: Wesleyan University
Lines: 38


	This is a note on the solution of one possible cause of the
"cannot start daemon" problem of lpr/lpd -- thought it should go in the
archives in case someone else runs into the same problem.  I encountered this
problem on DN2500 & DN3500 running SR10.2 with BSD as the nearly-exclusive
environment (not using Aegis printing).

	The Apollo lpr/lpd seems to differ from other BSDs in that it
apparently references the Domain name (set by ctnode) as well as servername
(created in /usr/spool/lpd by the system administrator).  Those names should
agree with the Internet hostname.  The hostname is set by default to the Domain
name (which by default is set to the hard disk name, I think, as Yan Lau
suggested in his note on how they resolved this problem).  IF YOU MODIFY
rc.local TO EXPLICITLY SET THE HOSTNAME (IGNORING THE SAGE ADVICE IN THE
COMMENTS THERE), THEN LPR/LPD WILL NOT SPAWN NEW DAEMONS.  The best solution
might be to get the lpr/lpd sources and recompile, but the easiest solution
seems to be:
		uctnode <your old node name>
		lcnode -me		(get your node number)
		ctnode <internet hostname you want to be> <your node #>
	then be sure the lines in rc.local that set hostname are
		commented out so the hostname will be the Domain node name
	then be sure that /usr/spool/lpd/servername contains the same
		name as the Domain name (hostname > /usr/spool/lpd/servername)
	then carefully check the protections on lpr, lpd, and the
		various spool directories as suggested in earlier notes
		on this problem
	of course, look in the BSD Systems Admin guide for other aspects
		of the setup such as printcap entries, etc.
This approach has the advantage that it doesn't require modifying sendmail.cf
to handle Internet mail, etc. (the "I refuse to talk to myself" problem that
started all of this!).

	Many thanks to the wonderful people who thought about this problem and
suggested things to look at.  I hope I've contributed back a little by making
it a little easier if someone else has this problem.

							David Todd