General discussion

Locked

Access problem with LPD control file

By ddiall ·
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?

This conversation is currently closed to new comments.

9 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

Access problem with LPD control file

by ddiall In reply to Access problem with LPD c ...

If you need more detail on something, please, do not hesitate to reply as I shall track the answers closelly.

Collapse -

Access problem with LPD control file

Hi!

This is a simple workaround that should work, I'm not sure.

But this should work since remote clients can print correctly.

Set up a remote printer locally on your box pointing to localhost and the printque you want to use and then printto this printer instead of 'lp' which is default.

This way the rights should be the same as for all other remote clients.

/Hasse

Collapse -

Access problem with LPD control file

by ddiall In reply to Access problem with LPD c ...

Poster rated this answer

Collapse -

Access problem with LPD control file

by ddiall In reply to Access problem with LPD c ...

[This concerns answer #1 from Hasse]

I already tried this some time ago... Actually I still have this setup configured for a regular matrix printer.

It didn't work then, so I tryied recreating this fake remote printer. The submission of the print job is successful, but no nothing comes out. Checking the print queues (with 'lpq') the job is there. The problem is that I received "Warning: no daemon present", but then I figured out the I was linking the *fake remote printer* to an already *remote printer*.

Linking the fake remote to a local printer works. So with the fax printer this workaround should work too! Anyway this is not a very elegant solution... I should have stated in the question that I wanted a *solution* not a workaround (my fault :-)

Can you (or someone else) provide more "juicy" information to solve this problem?

If in a couple of weeks time I don't get a satisfactory answer to I'll rate answer #1 as 'acceptable' for making me retry the fake remote scenario...

Collapse -

Access problem with LPD control file

by Bulch In reply to Access problem with LPD c ...

I think you MUST have 'lp' group (gid=7, members are 'daemon' and 'lp'). Try this.

Collapse -

Access problem with LPD control file

by ddiall In reply to Access problem with LPD c ...

I have the default RH6.0 setting for group 'lp':

lp::7:daemon,lp

Collapse -

Access problem with LPD control file

by ddiall In reply to Access problem with LPD c ...

Point value changed by question poster.

Some more points to this issue... Who has the answer?
Thank you all for reading such long postings.

Collapse -

Access problem with LPD control file

by ddiall In reply to Access problem with LPD c ...

Point value changed by question poster.

Collapse -

Access problem with LPD control file

by ddiall In reply to Access problem with LPD c ...

This question was closed by the author

Back to Linux Forum
9 total posts (Page 1 of 1)  

Related Discussions

Related Forums