blumzi / LAST_tools

Various LAST management tools
0 stars 0 forks source link

misformed IPs for no_proxy #10

Closed EastEriq closed 2 years ago

EastEriq commented 2 years ago

This line https://github.com/blumzi/LAST_tools/blob/a1f9e8dcee2cdcf0684731a6bee40fe1c8b9872c/sections/profile.sh#L93 seems to be doing something wrong:

ocs@last08e:~$ echo $no_proxy
127.0.0.1,10.23.11,10.23.12,10.23.13,10.23.14,10.23.15,10.23.16,10.23.17,10.23.18,10.23.19,10.23.110,10.23.111,10.23.112,10.23.113,10.23.114,10.23.115,10.23.116,10.23.117,10.23.118,10.23.119,10.23.120,10.23.121,10.23.122,10.23.123,10.23.124,10.23.125,10.23.126,10.23.127,10.23.128,10.23.129,10.23.130,10.23.131,10.23.132,10.23.133,10.23.134,10.23.135,10.23.136,10.23.137,10.23.138,10.23.139,10.23.140,10.23.141,10.23.142,10.23.143,10.23.144,10.23.145,10.23.146,10.23.147,10.23.148,10.23.149,10.23.150,10.23.151,10.23.152,10.23.153,10.23.154,10.23.155,10.23.156,10.23.157,10.23.158,10.23.159,10.23.160,10.23.161,10.23.162,10.23.163,10.23.164,10.23.165,10.23.166,10.23.167,10.23.168,10.23.169,10.23.170,10.23.171,10.23.172,10.23.173,10.23.174,10.23.175,10.23.176,10.23.177,10.23.178,10.23.179,10.23.180,10.23.181,10.23.182,10.23.183,10.23.184,10.23.185,10.23.186,10.23.187,10.23.188,10.23.189,10.23.190,10.23.191,10.23.192,10.23.193,10.23.194,10.23.195,10.23.196,10.23.197,10.23.198,10.23.199,10.23.1100,10.23.1101,

A consequence of this appears to be that matlab is no more capable to read the power switches via ReST (addressing the switches by IP), and crashes in the attempt of (unsetting no_proxy, the capability is restored)

EastEriq commented 2 years ago

Note that no_proxy=10.23.1.0/22 is simpler and better (doesn't cause trouble to matlab's webread):

ocs@last08e:~$ export no_proxy=10.23.1.0/22
ocs@last08e:~$ echo $no_proxy
10.23.1.0/22
ocs@last08e:~$ matlab -nosplash -nodesktop

                            < M A T L A B (R) >
                  Copyright 1984-2020 The MathWorks, Inc.
                  R2020b (9.9.0.1467703) 64-bit (glnxa64)
                              August 26, 2020

To get started, type doc.
For product information, visit www.mathworks.com.

AstroPack startup addpath count: 25
AstroPack startup done: /home/ocs/matlab/AstroPack/matlab/startup/startup
>> t=inst.tinycontrolIPpowerSocket('01_2')

t = 

  tinycontrolIPpowerSocket with properties:

    Outputs: [0 0 1 1 0 0]

>> 
EastEriq commented 2 years ago

(assuming that 10.23.1.0/22 is really a legal syntax; maybe matlab just works because that form has no side effect)

blumzi commented 2 years ago

No it is not valid syntax, that's why I have to use the whole list.

The environment variable is used by wget and set by pam, that's what constrains the syntax.

The list was botced, fixed by commit 72512a9

EastEriq commented 2 years ago

On the syntax, I agree. I've educated myself a bit on the net too, and I've learned that ranges in syntax are not allowed (that is, neither *, nor 1-255, nor /24, etc.)

As for matlab and inst.tinycontrolIPpowerSocket (present implementation, using webread; the discussion whether to migrate it to matlab.net.http is still relevant): I made some more tests, and it turns out that what crashed matlab were not the illegal IPs in the list, but the fact that the blotched list ended with a comma. Idiotic as it is. I note it here for the record, though solved by https://github.com/blumzi/LAST_tools/commit/72512a9121778f1c571018419551a2c22ee29c8c.

blumzi commented 2 years ago
  1. Eran uses webread to reach sites outside the Institute, i.e. he needs the http_proxy variable to point to the Weizmann http proxy
  2. I could not find within the weboptions used by webread any way of telling it not to use proxy.
  3. I found that https://www.mathworks.com/help/matlab/ref/matlab.net.http.httpoptions-class.html can do it via Credentials.UseProxy = false (as per the pswitch.m example I sent)

I thus suggest we use matlab.net.http in inst.tinycontrolIPpowerSocket with Credentials.UseProxy = false, to isolate it from the environment, which itself is needed by Eran's use of webread.

On Mon, Oct 24, 2022 at 7:22 AM EastEriq @.***> wrote:

On the syntax, I agree. I've educated myself a bit on the net too, and I've learned that ranges in syntax are not allowed (that is, neither *, nor 1-255, nor /24, etc.)

As for matlab and inst.tinycontrolIPpowerSocket (present implementation, using webread; the discussion whether to migrate it to matlab.net.http is still relevant): I made some more tests, and it turns out that what crashed matlab were not the illegal IPs in the list, but the fact that the blotched list ended with a comma. Idiotic as it is. I note it here for the record, though solved by 72512a9 https://github.com/blumzi/LAST_tools/commit/72512a9121778f1c571018419551a2c22ee29c8c .

— Reply to this email directly, view it on GitHub https://github.com/blumzi/LAST_tools/issues/10#issuecomment-1288534218, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHQOOK7BCO3XZWLDW3KSTWEY2LRANCNFSM6AAAAAARMAR324 . You are receiving this because you modified the open/close state.Message ID: @.***>

EastEriq commented 2 years ago

We have a few questions here:

  1. is matlab honoring at all $no_proxy for webread? (since it crashes when it is blotched - probably)
  2. is matlab honoring $http_proxy for webread? We have concluded yes.
  3. is it honoring $no_proxy for tcp, udp, modbus? (we have uses of all of them to local hosts)

I'd suggest that we run some sniff tests for all four protocols, to make an informed decision. In principle I'd rather see as desirable that an environment variable rules consistently all processes, if it really does so.

blumzi commented 2 years ago

All the code that talks to equipment at the observatory MUST NOT use proxy

On Mon, Oct 24, 2022 at 9:22 AM EastEriq @.***> wrote:

We have a few questions here:

  1. is matlab honoring at all $no_proxy for webread? (since it crashes when it is blotched - probably)
  2. is matlab honoring $http_proxy for webread? We have concluded yes.
  3. is it honoring $no_proxy for tcp, udp, modbus? (we have uses of all of them to local hosts)

I'd suggest that we run some sniff tests for all four protocols, to make an informed decision. In principle I'd rather see as desirable that an environment variable rules consistently all processes, if it really does so.

— Reply to this email directly, view it on GitHub https://github.com/blumzi/LAST_tools/issues/10#issuecomment-1288716740, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHQOLMJECJFT4ED23NYQTWEZIMZANCNFSM6AAAAAARMAR324 . You are receiving this because you modified the open/close state.Message ID: @.***>