[Nut-upsuser] New NUT user with HP R3000XR problem

[Arjen de Korte]

Citeren Brother Railgun of Reason <alaric op caerllewys.net>:

>> 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