Hi, lpr/lpd do not function properly to permit faxing. At this point, I'm not really sure if the problem is with the efax package or lpr/lpd. I followed the instructions in /usr/doc/HOWTO/mini/Fax-Server to setup a fax server, however whenever I tried to fax something, the fax wouldn't go through. It appears that when I use lpr to try to fax something, efax never dials the number. However, using fax directly from the command line works fine. I hacked up /usr/bin/fax (lpd's input filter for faxing) and traced this to the following: When /usr/bin/fax is executed, it reads the fax lock file to ascertain the file with configuration options (the impotatnt one being the phone number in this case). The configuration file is dynamic (I'm no printing hacker, but I would assume its written by lpd). After getting the name of the configuation file, the fax program tries to read the file, but can't because the user who executed the fax program (uid: 4 (lp), gid: 0 (wheel)) does not have permission to read the dynamically generated configration file owned by bin.lp , permission 640. At the moment I'm not sure which program is at fault, but I'm guessing its lpr/lpd. I temporarily fixed the problem by chmod g+s /var/spool/fax. A Pertinent info: Program Versions: [root@nut bleh]# rpm -q lpr efax lpr-0.35-1 efax-0.8a-11 [root@nut bleh]# Fax entry in printcap: fax:\ :lp=/dev/null:\ :sd=/var/spool/fax:\ :if=/usr/bin/faxlpr: (faxlpr = symlink to /usr/bin/fax -- part of efax) It would be nice if you guys added the ability to add faxing through printtool :].
lpr/lpd doesn't make the config file you speak of for faxing. I'd suggest checking your faxing program. ------- Additional Comments From 09/18/99 20:09 ------- Sorry for the delay, but I was on vacation. It does though create a file, or at least it is creating it on my system. The file needs to be created or else the /usr/bin/fax would not know what number to dial. To fax a file, the following command is evoked, lpr -Pfax -J<phone number> . From /usr/bin/fax (part of standard efax package) Around line 588, is the following: cd $FAXDIR cfile=`cat \`tail -1 lock\`` # configuration file --> file with phone # number The problem is, this file is not readable by the user who executed /usr/bin/faxlpr (user info mentioned in previous post). Since th efile is not readable, the number to fax to can not be gained, and as such, nothing happens. Again, all this is on a standard rh6.0 system, and I followed instructions as given in /usr/doc/HOWTO/mini/Fax-Server. As mentioned in my prior most, chmod g+s /var/spool/fax/ fixes the problem, because then all files writen to the spooling directory (including the configuration file) are owned by group wheel, and this permits the fax program to read the file (since it is executed gid: 0).
Just to clarify a little bit, the config file name is stored as the last line in the lock file. The config file, with defaults settings, is unreadable by the user who executes the fax filter. On my system, after I have sent the command to fax (lpr -Pfax -J phone) the content of /var/spool/fax/lock is [root@nut fax]# cat lock 27386 cfA052AqC86Yh [root@nut fax]# The last line, is the name of the config file. in this instance, it contains: [root@nut fax]# cat cfA052AqC86Yh H<hostname hidden to protect the innocent> Proot J<phone # hidden to protect the innocent> Cnut.dhs.org Lroot fdfA052AqC86Yh UdfA052AqC86Yh Noutput [root@nut fax]# By default, this file, is not readable to the user who ran the fax filter.
OK, I see now. What happens if you try this with the latest lpd from Raw Hide? ------- Additional Comments From 09/21/99 22:00 ------- lpr (lpr-0.41-2) in rawhide does the trick. Thanks.
Commit pushed to master at https://github.com/openshift/origin https://github.com/openshift/origin/commit/f62161fff179bd6bcc9628ce689810502519f1c4 integration/diag_nodes_test.go: fix test flake issue 4499 also now returns the node config from allinone helper.