rlpdaemon vs. nslookup (LPD Protocol)

[Richard Stern_2]

Is there a requirement that rlpdaemon be able to verify the IP address of an incoming LPD job before it will spool it?

A foreign system is sending the jobs and it is not in our DNS nor in the public Internet DNS.

All I get in the LPD log is the message:
Host name for your address (x.x.x.x) unknown

I don't see any requirement for name lookup in any of the manuals/documents I have searched.

Thank you.

[James A. Donovan]

Are you running the rlpdaemon via inetd? If so, do you have /var/adm/inetd.sec configured? Is there an entry in the inetd.sec file for the rlpdaemon (printer) service?

The inetd.sec file would cause a hostname lookup to be performed.

[Richard Stern_2]

Inetd: Yes, it is run via Inetd

Inetd.sec: No - Inetd.sec is empty (default)
Definitely no entry for printing.

[James A. Donovan]

add the line:

printer allow

to the inetd.sec file and then restart inetd using "inetd -c"

[Richard Stern_2]

I presume inetd.sec's job is to determine if the service (rlpdaemon) should be run when the traffic arrives. (ie - valid ip address)

It is my understanding that if a service is not listed it is allowed to run.

Presumably rlpdaemon is running since lpd.log has lots of the "Host name unknown" messages, and presumably rlpdaemon is the only process that is adding those messages.

We temporarily added the address in question to /etc/hosts and the test job did physically print out. So everything worked w/ an empty inetd.sec file.

Have I gotten this wrong?

[James A. Donovan]

rlpdaemon via inetd depends on inetd.sec for authentication. The presence of inetd.sec causes inetd to issue a hostname lookup. Since the box in question didn't have a DNS or /etc/hosts entry, the hostname lookup failed. This would be the source of the error message. It's most likely that the rlpdaemon is interpreting this as an authentication failure, and therefore not spooling the print job.

[Michael Steele_2]

In inetd.sec try this instead:

printer deny x.x.x.x

Regarding "...I presume inetd.sec's job is to determine if the service (rlpdaemon)..."

'inetd.sec' is a firewall. It's basically the first firewall upon which all others are based. It still filter's ip packets's by ip address just like all firewalls.

Regarding "...It is my understanding that if a service is not listed it is allowed to run..."

Not entirely true. A listed service can have both allow and deny entries. See the above 'deny' example.

'rlpdaemon' is a sub set of the inetd super daemon and is active as long as required.

See this link:

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B3901-90010/B3921-90010_top.html&con=/hpux/onlinedocs/B3921-90010/00/07/746-con.html&toc=/hpux/onlinedocs/B3921-90010/00/07/746-toc.html&searchterms=log%7clpd&queryid=20031112-173618

#####################################

Note: lpsched -v for more information recorded in lpd.log.

#####################################

Also, inetd.sec can be replaced with $HOME/.rhosts or /etc/host.equiv for access. See the above link about:

"...When rlpdaemon is not started by inetd(1M) , all requests must come from one of the machines listed in the file /etc/hosts.equiv or /var/spool/lp/.rhosts...."

[Kurt Renner]

I am experiencing the same problem this post relates to. There's no evidence from this post that the problem was actually resolved. IS there a solution to this problem? I tried the suggestions given to no avail.

I found the following document that appears to suggest that HP will do nothing to fix the problem. They appear to be blaming the problem on Microsoft.

http://itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000062922557