the /etc/hosts.allow
file. Here I've hit a problem. The file, both the internals of it
(which is a mass of examples with nearly no explanations) and the man
page, are either circular definitions, or missing ones, grossly
missing. One glaring example, in the man page, the single most commonly
used
the hosts_access man page:
ALLThe universal wildcard, always matches.
I can't figure out how to use /etc/hosts.allow. I'm not
sure if it is, or is not, affecting my rpcbind.
The man page for rpcbind suggests it should, and you can find out (again, from
the man page):
-l Turn
with my newly attached
Zaurus, to my trusty FreeBSD server. I have gotten past several
problems, began googling error messages, and hit the /etc/hosts.allow
file. Here I've hit a problem. The file, both the internals of it
(which is a mass of examples with nearly no explanations) and the man
page
On Sat, Oct 08, 2005 at 03:45:23PM -0400 I heard the voice of
Chuck Robey, and lo! it spake thus:
I'm not sure if it is, or is not, affecting my rpcbind.
Someone else pointed out hosts_access(5). I just wanted to point out
that unless you did something to it, it's probably not. The file is
Is inetd wrapping and hosts.allow supposed to support IPv6 addresses?
Because it isn't for me. Not only that but added an IPv6 address to
hosts.allow seems to prevent processing of IPv4 anddress on that line.
If it should and is broken I will submit a PR. If not I will look and
see if I can
On Tue, 16 May 2000 16:10:28 -0400
James Housley [EMAIL PROTECTED] said:
jim Is inetd wrapping and hosts.allow supposed to support IPv6 addresses?
jim Because it isn't for me. Not only that but added an IPv6 address to
jim hosts.allow seems to prevent processing of IPv4 anddress on that line
v6 address with `[' and `]'.
Like this? Would you like me to submit a PR with this or can you commit
the changes or better ones???
Jim
--
Studies show that 1 out of every 4 Americans suffer some form of
mental illness. So look at your three best friends, if they
are okay it is YOU!
--- hosts.allow Fri
: [fe80::]/10
Please see manpage for host_access(5).
jim Would you like me to submit a PR with this or can you commit
jim the changes or better ones???
jim +# To use IPv6 addresses you must enclose them in []'s
jim +ALL : [fe80::/10]
To add example in /etc/hosts.allow is good idea. But, use
Sheldon Hearn scribbled this message on Jun 21:
You can expect the internal wrapping fixes and the SIGHUP bugfix to be
merged back to STABLE soon (within a week). I'm in no rush, and I'm glad
I didn't rush, since David Malone has already uncovered a bug in the
handling of maxchild, which I
on another note, LIBWRAP_INTERNAL looks like it must be defined for
internal services to be wrapped, yet it is not defined during freebsd's
compile -- only LIBWRAP is. yet freebsd's inetd man page says that internal
services may be wrapped. since it is not currently so by default, perhaps
On Sun, 20 Jun 1999 17:49:59 MST, Aaron Smith wrote:
unfortunately incoming telnet was still denied. at first i tried
HUPping inetd to reread the hosts.allow, but after looking at the
source it appears to re-read its information each time hosts_access is
called. has anyone else had problems
There was a bug in inetd in which ment that if you HUPed inetd it could
get confuesed about the name of the services. This is probably what you
are seeing. Sheldon has just committed a fix for this.
The wrapping of internal services isn't quite working properly yet. Sheldon
has committed a
In message 19990621110303.a7...@walton.maths.tcd.ie, David Malone writes:
wrapped (and it isn't possible to wrap tcp nowait services even with tcdp).
Is that what you meant to say, or am I getting confused? Did you mean udp,
or wait?
Of course - I ment tcp wait services.
David.
. at first i tried HUPping
inetd to reread the hosts.allow, but after looking at the source it appears
to re-read its information each time hosts_access is called. has anyone
else had problems updating this file and getting inetd to reflect the new
behavior?
note that tcpdmatch telnetd client_host
14 matches
Mail list logo