I’m setting up a fax server on RH 6.0: the network clients send fax jobs to a remote LPD printer.
The fax number is specified as the print job name, through a command like ‘lpr -Pfax -J5551234 file.ps’. The job name (and other info) resides in the control file (CF henceforth) generated by the print subsystem for each job.
Then the filter script parses the CF to get the fax number and submit the job to the fax subsystem (mgetty+sendfax).
No sweat sending faxes from network clients, theproblem arouses when submitting jobs locally on the server. After snooping a bit, I found that the filter has no permission to open the CF for reading.
Printing from a network client, this set of files (cf* control, df* data) appears in the spooldir:
-rw-rw—- root root cfA011nautilus
-rw-rw—- root root dfA011nautilus
When printing a job locally, the spooler generates these files:
-rw-rw—- bin lp cfA029AEahlSz
-rw-rw—- root lp dfA029AEahlSz
Apart from the filenames, the main difference is in the ownerships. The filter script runs with uid=4(lp) and gid=0(root), belonging to these groups 0(root), 1(bin), 2(daemon), 3(sys), 4(adm), 6(disk), 10(wheel). Note that there is no ‘lp’ group, what is rather strange…
I traced the syscalls on ‘lpr’ and ‘lpd’ to understand the different ownerships. (…) Anyway the difference shouldn’t matter, if the script ran belonging to the group ‘lp’ too.
So, in short, the problem is that the print filter script cannot read the CF when the job is submitted locally, thus unable to retrieve the fax number from it. How can I solve this issue?
Maybe by changing the mode of the the ‘lpr’ binary to manipulate the ownership of the control file; but that seems risky. Or by making the filter script run as part of the ‘lp’ group; but that means I have to hack the ‘lpd’ source code…
Does anyone see a simpler workaround?