<div dir="auto">My understanding was that this is about logins defined in upsd.users file, that can be used to limit certain operations. <div dir="auto"><br></div><div dir="auto">So upsd decides how to filter operations (thinking of it and revising the docs, I don't believe there are now options to bind an upsd login to only some particular devices represented on this upsd), and upsmon decides how to log in (e.g. how many sessions it needs from same process into same hostname and login to upsd), and a human admin decides where to set or not the particular name and password in a NUT client.<div dir="auto"><br></div><div dir="auto">Notably for the confusion, some networked UPSes and their drivers do have logins independently of ones defined by a NUT deployment (be it SNMP community or user names, or NetXML httpauth credentials, or dummy-ups logins to another NUT, or...) which are used as part of vendor protocol and so configuration of this or that NUT driver. I checked briefly that these strings are not seen in an `upsc` listing of dstate ;)</div><div dir="auto"><br></div><div dir="auto">Jim</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 28, 2021, 10:25 Roger Price <<a href="mailto:roger@rogerprice.org">roger@rogerprice.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The NUT protocol provides a LOGIN <upsname> "to limit access to the UPS unit(s) <br>
to which it is attached".  This implies that it is a "login to the ups" feature <br>
and not a "login to upsd" feature.  However if upsd is attached to two UPS's, <br>
and upsmon logs into one, and then the other, the login to the second is <br>
rejected ALREADY-LOGGED-IN.<br>
<br>
Question: Is it "Login to UPS" or "Login to upsd daemon"?<br>
<br>
I propose saying in the RFC that LOGIN is to the UPS, with a note saying <br>
current practice does not follow this and behaves as a login to the upsd <br>
daemon.<br>
<br>
The response to LIST CLIENT ups1 is typically<br>
<br>
BEGIN LIST CLIENT ups1<br>
CLIENT ups1 ::1<br>
CLIENT ups1 198.51.100.2<br>
END LIST CLIENT ups1<br>
<br>
Questions:<br>
<br>
1) Does this mean that one or two clients are logged into ups1 ?<br>
<br>
2) Why doesn't the listing say who (presumably an identifiable master/primary) <br>
is logged in?<br>
<br>
I would expect to see a response such as<br>
<br>
BEGIN LIST CLIENT ups1<br>
CLIENT ups1 ups-manager     ::1 198.51.100.2<br>
CLIENT ups1 ups-2nd-manager 198.51.100.36<br>
END LIST CLIENT ups1<br>
<br>
I propose saying in the RFC that the response is still the subject of further <br>
study.<br>
<br>
Roger<br>
<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a></blockquote></div>