Citeren Brother Railgun of Reason <[email protected]>:
Oops, looking at the code I saw this isn't a warning, but a (fatal) error
instead (this was not one of the most descriptive error messages I ever
wrote). I now recall that this value is OS dependent, so you probably
want/need to limit this in upsd.conf through the MAXCONN parameter (which
in your case seems to be mandatory).
Ah, ... yeah, that would have been better than patching the code,
wouldn't it?
*sheepish*
I missed that parameter. I'll undo my patch and try using the maxconn
param instead.
As just mentioned, my studies appear to indicate that this is a tunable
kernel parameter which, on Solaris, defaults out-of-the-box to 256.
It is.
I'm not quite sure what would be the better thing to do in case the
(default) MAXCONN value is too high:
1) Bail out with a more descriptive error message
2) Adjust the number of connections to the maximum allowed (with message to
syslog)
I think it would be much more user friendly to do the latter, but opinions
on this are welcomed.
Given that this varies by OS *but* may be tunable, my inclination would
be to adjust the connections to the max available if less than MAXCONN,
emit a warning in syslog and on the console, and document in the sample
upsd.conf that depending on OS this MAY be a tunable parameter.
I think the safest we can do is, by default use the maximum number
available (instead of fixing this to 1024). People would still be able
to lower this value should they wish to (in order not to waste
resources if this happens to be a very high value). But we *must* bail
out (with a more descriptive error message) if people deliberately
request a number higher than the system allows. You'll run into
problems (and this may not be immediately after startup) if you exceed
the maximum number of connections, so this must be fixed. The only way
to guarantee this happens, is to refuse to start.
[...]
Ah, so the behavior is as *intended*, but the documentation has gotten
out of step with the intent. I see.
If this change was made for security reasons, perhaps this goal might be
aided by adding a netblock ALLOW or ACCEPT directive? For example, with
two subnets, I might specify:
LISTEN 127.0.0.1 3493
ACCEPT 127.0.0.0/8
LISTEN 10.24.32.14 3493
ACCEPT 10.24.32.0/24
ACCEPT 10.24.33.0/24
upsd could simply refuse connections from outside the netblocks it had
been told to ACCEPT, without doing any further authentication.
For IP based access control, you'd better use a firewall which can do
this much more efficiently than we ever can. We actually *removed*
this and now use tcp_wrappers only for IP based *user* level access
control.
Best regards, Arjen
--
Please keep list traffic on the list
_______________________________________________
Nut-upsuser mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
