Hide Forgot
Description of Problem: The fam utility is not working correctly with tcp wrappers. Tcp wrappers reports via /var/log/messages that it cannot get client address. Version-Release number of selected component (if applicable): 2.6.4-11 Steps to Reproduce: 1. Configure /etc/hosts.allow as: ALL: LOCAL, 127.0.0.1 2. Configure /etc/hosts.deny as: ALL: ALL 3. Login using KDE as your desktop environment Actual Results: The KDE login hangs will initializing services. TCP Wrappers repeatedly logs this to /var/log/messages: Jan 13 08:36:19 pcp096489pcs xinetd[9692]: warning: can't get client address: Transport endpoint is not connected Jan 13 08:36:19 pcp096489pcs xinetd[9692]: libwrap refused connection to sgi_fam from 0.0.0.0 Expected Results: KDE login should not hang. TCP Wrappers should be able to resolve which host that fam is connecting as. Additional Information: I do not think that there is a severity rating appropriate. I would classify this bug as moderate as the work around is to disable tcp wrappers or not use KDE. Disabling tcp wrappers is not allowed in many businesses, including my own. Regards, Joe Kotran
I don't think this is fam related. libwrapper always prints that for fam because of a bug in xinetd where it looks at the wrong socket. I get a few of these at startup, but I can still log in to KDE. Even with the tcp wrappers setttings above. Where exaclty is is blocking?
Sorry, but I cannot be more exact. The KDE login process hanges at the initializing services step. The icon blinks indefinitely and the computer thrashes as xinetd logs error messages to /var/log/messages. I am quite surprised to hear that you cannot recreate this problem. I have verified it on four different computers. I am curious to know if I am missing or doing something wrong. Regards, Joe Kotran
Bero, have you seen this? It seems pretty bad for KDE, but I'm not at all sure fam is to blame.
Haven't seen this (guess nobody tried using tcp wrappers with fam yet). Does upgrading xinetd to the version from rawhide fix this? On the first look, this seems to be an xinetd/libwrap issue.
Bero, I'm not sure at all the fam message has anything to do with it. I get that all the time, and fam still works. We traced it once, and it was some problem with xinetd and wait = yes RPC services, where it looked at the listening instead of the connected socket.
Thist problem should be fixed in xinetd 2.3.4-0.8