I am assuming you mean the /etc/hosts.allow file that you had to add an entry? If so, here is what I have learned: 1. If slapd has been compiled against libwrap, then it will be under tcpwrapper control and does not have to run under inetd. ldd `which slapd`|grep libwrap libwrap.so.0 => /lib/libwrap.so.0 (0x4016f000) I assume this explains why some services from some distros react differantly. 2. As the hosts_access man page reports: LOCAL Matches any host whose name does not contain a dot character. Therefore, I would check your /etc/hosts file. I haven't tested this theory, but I wonder if you had an entry(s) such as 127.0.0.1 localhost localhost.mydomain.com 192.168.1.1 myhost myhost.mydomain.com 192.168.1.2 anotherhost Perhaps, the 'dots' in the first two entries exclude you from using the LOCAL wildcard, whereas the third entry would work as expected? HTH v/r -Mike On Tue, Oct 15, 2002 at 10:35:20PM -0400, George Toft wrote: You bring up a good point. LDAP is not under inetd control, but I had to add 127.0.0.1 (LOCAL wasn't good enough) to connect to my local LDAP server. What's the explanation for this? George Mike Starke wrote: > > No need to eat crow......I think this was the point I > was trying to make. Some services are (undr wrapper control), > some are not, some used to be and no longer are, and then > some behave just as I expect, those that are only run > under inetd. It is the inconsistencies from service to > service, and from year to year (your case) that I find > confusing. I think you mentioned chasing down an issue > with SNMP and I with ldap; seems to me one should just > 'know' what's under wrapper control and what is not. > > v/r > Mike > > On Tue, Oct 15, 2002 at 12:18:04AM -0400, George Toft wrote: > Crow chomp chomp > > I do not understand . . . > > I have tested your theory and your are right (as of 2002). I know for a > fact that in 2000, what I described worked as described. I have seen it > in action - I tossed IP's into /etc/hosts.deny because they were abusing > our machines an as soon as I did so, the abuse stopped. We did not have > Apache under inetd control. > > I stand corrected. > > George > > > Digital Wokan wrote: > > > > Apache is only under the control of /etc/hosts.allow|deny when you set it up > > to start as an inetd service instead of in standalone mode. For a low use or > > testing site, this may be okay, but it is a large bottleneck to high-usage > > sites, where a firewall-based blocking solution would make more sense to use > > against abusers. > > > > On Thursday 10 October 2002 20:40, George Toft wrote: > > > What makes you think Apache is not? Whe I was at the .com in LA, we had > > > a script that analyzed Apache log files, and dropped the abuser's IP > > > netowrk into /etc/host.deny for 48 hours. That locked him (and a chunk > > > of his ISP) out so he couldn't redial and continue the attack. > > > > > > I know for a fact that SNMP is under tpc wrapper control - that was one > > > of the biggest bitches to solve. > > > > > > SSH is also controlled by TCP wrappers - I use it as redundancy in case > > > I make stupid typos and open SSH to my $EXTIF instead of my $INTIF. I > > > did this, and I discovered it through looking at my logs. > > > > > > What I discovered two weeks ago about OpenLDAP was that LOCAL is not the > > > same as 127.0.0.1. To every other service I have used in the last 6 > > > years it was, but noooo - not OpenLDAP. > > > > > > Anyway, it's called TCP wrappers, not inet wrappers, because it affects > > > all TCP services. My hosts.allow file looks like this: > > > ALL: LOCAL, 127.0.0.1, 192.168.55. > > > which supports my LDAP, MySQL, Apache and DNS servers. The 192.196.55 > > > LAN is another interface that needs DNS and HTTP services. > > > > > > George > > > > > > Mike Starke wrote: > > > > Years ago, I seem to recall that the only services > > > > under control of hosts.allow & hosts.deny were those > > > > under inetd (/etc/inetd.conf). > > > > > > > > I just spent the past hour trying to figure out why I couldn't > > > > connect to my new ldap server from a remote site; come to find > > > > out all I needed was a simple entry in /etc/hosts.allow Being that > > > > slapd runs as a deamon, I stared at my slapd.conf file and couldn't > > > > find any reason why a connection was denied. > > > > > > > > Simple question: How does one know when a service is under > > > > tcpwrappers? Apache & Bind are not, what should have made > > > > me think slapd was? > > > > > > > > v/r > > > > Mike > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > > > > To subscribe, unsubscribe, or to change you mail settings: > > > > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > > > To subscribe, unsubscribe, or to change you mail settings: > > > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > > To subscribe, unsubscribe, or to change you mail settings: > > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change you mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change you mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change you mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss