ENH: (SCOPE) Use of IPs and logging for printing

[xresende]

still need to wait for control subnet static IPs to be assigned to the scopes

[anacso17]

Hi @xresende! We used to use the IPs before and changed to use hostnames (unfortunately the commit history - #955 - doesn't have the reason, but I remember something related to the IPs changing frequently), why are we reverting this?

[xresende]

Hi @xresende! We used to use the IPs before and changed to use hostnames (unfortunately the commit history - #955 - doesn't have the reason, but I remember something related to the IPs changing frequently), why are we reverting this?

@anacso17 , these hostnames from the CNPEM domain are not being resolved properly by DNS when the class is used outsize the control system subnet, such as for FAC's desktops for data acquisiton only. That is why I decided to switch back to IPs, after consulting with Eduardo and Afonso in the control room. As far as I understand these are static IP numbers. Is this correct, @afonsoln ?

[fernandohds564]

Hi @xresende! We used to use the IPs before and changed to use hostnames (unfortunately the commit history - #955 - doesn't have the reason, but I remember something related to the IPs changing frequently), why are we reverting this?

@anacso17 , these hostnames from the CNPEM domain are not being resolved properly by DNS when the class is used outsize the control system subnet, such as for FAC's desktops for data acquisiton only. That is why I decided to switch back to IPs, after consulting with Eduardo and Afonso in the control room. As far as I understand these are static IP numbers. Is this correct, @afonsoln ?

@xresende, do we want this class to work out of the control system network? wouldn't it be safer if it only worked inside the network?

[xresende]

Hi @xresende! We used to use the IPs before and changed to use hostnames (unfortunately the commit history - #955 - doesn't have the reason, but I remember something related to the IPs changing frequently), why are we reverting this?

@anacso17 , these hostnames from the CNPEM domain are not being resolved properly by DNS when the class is used outsize the control system subnet, such as for FAC's desktops for data acquisiton only. That is why I decided to switch back to IPs, after consulting with Eduardo and Afonso in the control room. As far as I understand these are static IP numbers. Is this correct, @afonsoln ?

@xresende, do we want this class to work out of the control system network? wouldn't it be safer if it only worked inside the network?

@fernandohds564 ,

i agree that, ideally, raw access to accelerator devices should only be available from within the control system network. More generally, my view is that access to accelerator devices from outside the control network should happen only through EPICS PVs, preferably exposed through EPICS Gateways implementing read-only access, rather than through direct access to device interfaces. that would provide a cleaner separation between the control system and the corporate network while still allowing data consumers to access the information they need.

however, the situation with these oscilloscopes is currently a bit special. they are being used as a temporary acquisition devices workaround until the bergoz electronics acquisition system is fully operational. some of these scopes are already connected to the CNPEM corporate network and are reachable from outside the control subnet today. my understanding is that this was done to facilitate occasional access from windows machines and other non-control-system hosts, such the pulsed magnet group's accesses to read and save scope configuratios (as they are both machine temp devices and diagnostics tools)

in that context, using hostnames versus IP addresses does not really change the access model or security risk. the devices are already reachable from the corporate network. the practical issue addressed by this PR is that the CNPEM hostnames are not being resolved correctly outside the control subnet, which prevents us from performing data acquisition from, for example, FAC desktops and from other non-control-system machines.

also, the current Keysight device interface is read-only in practice: it retrieves waveform and configuration data but does not modify the oscilloscope settings, only reinforces the default operation configuration. therefore, the goal of this change is simply to restore reliable data acquisition from those hosts that already have network access to the devices.

if, in the future, we decide that access from outside the control subnet should be disallowed, i believe that should be addressed at the network and device-access level rather than through hostname resolution vs IP.

[xresende]

Hi @xresende! We used to use the IPs before and changed to use hostnames (unfortunately the commit history - #955 - doesn't have the reason, but I remember something related to the IPs changing frequently), why are we reverting this?

@anacso17 , these hostnames from the CNPEM domain are not being resolved properly by DNS when the class is used outsize the control system subnet, such as for FAC's desktops for data acquisiton only. That is why I decided to switch back to IPs, after consulting with Eduardo and Afonso in the control room. As far as I understand these are static IP numbers. Is this correct, @afonsoln ?

I talked to @afonsoln about these IPs. I think these scopes should have static IPs from the control subnet and should be used in our classes. He will discuss this with eduardo.

[afonsoln]

Talked to Eduardo, we will add them to the controls network.