Recceiver - Add option to pass EPICS env variables

[tynanford]

https://github.com/ChannelFinder/recsync/blob/master/client/castApp/src/dbcb.c#L13

These EPICS env variables already get passed from reccaster to recceiver. There currently is no way to add them to channel finder easily though. It would be nice to have a settings list for these such as ENGINEER, LOCATION, etc.

[tynanford]

Discussed this with Kay. The plan is to first create a new setting in recceiver like this that allows you to specify which variables to push to CF and what their property name should be

# List environment variables that should be written as channel finder properties
#
# Comma-separated list of VARIABLE:PropertyName,
# specifying which environment VARIABLEs to pass on to the channel finder
# and defining the corresponding PropertyName
environment_vars=ENGINEER:Engineer,EPICS_BASE:EpicsVersion,PWD:WorkingDirectory

Second step would be to have reccaster simply send all epics ENV vars instead of the hard coded list.

Third step would be to address this issue - ChannelFinder/ChannelFinderService#48

[tynanford]

@kasemir @shroffk @mdavidsaver

For step 2, we would like reccaster to send the full list of epics ENV variables instead of the hard coded list. I am having trouble finding a good way to get the full list. epicsEnvShow gets the full list but it prints the values. There isn't an epicsEnvGet function in libcom.

reccaster could use the logic from epicsEnvShow to call getenv and get the values. But I think that would mean being tied to a particular OS or having to do OS checking in reccaster

https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/src/osi/os/default/osdEnv.c#L69

There is a list in epics called env_param_list which contains these vars: https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/src/env/envDefs.h#L47

I can get those sending in reccaster but that is just trading out one hard coded list for another

    /* only gets list of EPICS env vars */
    const ENV_PARAM **ppParam = env_param_list;

    while (*ppParam != NULL && !ret) {
        const ENV_PARAM *pParam = *(ppParam++);
        const char *val = pParam->name;
        printf("%s\n", val);
        if(val && val[0]!='\0')
            ret = casterSendInfo(caster, 0, envs[i], val);
        if(ret)
            casterMsg(caster, "Error sending env %s", envs[i]);
    }   

P.S. step 1 is here: ChannelFinder/recsync#55

[mdavidsaver]

For step 2, we would like reccaster to send the full list of epics ENV variables instead of the hard coded list. ...

Be aware that process environment may sometimes contain secrets. (eg. X credentials) And will certainly contain extraneous junk (eg. $LS_COLORS). This drove my original decision to send only certain variables.

[kasemir]

Yeah, I think we came to the same conclusion.
Slight bummer that you need to configure this twice:

1. On IOC, configure which env. vars to send
2. In recceiver, configure which ones to save (and under what name)

But having the recceiver tell the IOC which env vars to send would add to the protocol, and also allow it so request the "secret" variables.

[mdavidsaver]

That said, Linux, Mac, and Windows have environ.

[kasemir]

Bummer. There isn't even a call epicsEnvGet. There's ..Set, ..Unset, ..Show, but nothing to 'get'.
So even if you hardcode the list, is there an OS-independent way to get the value?

[kasemir]

If we can't list env. vars, and maybe don't want to send all of them anyway, why not side-step the problem:

Don't send environment variables.
Have a separate sendAdditionalStuff("name", "value") type of call for the recsync module
So in the startup file, instead of

epicsEnvSet("ENGINEER", "Fred")

we then have

sendAdditionalStuff("ENGINEER", "Fred")

[tynanford]

interesting... at ALS we use IOC stats and set the ENGINEER in all our IOCs now. So would a combination of both approaches be better? That would reduce the need for 2 lines for "standard" variables

Keep the hard coded list in dbcb.c and use the new environment_vars preference setting. Then add the new sendAdditionalStuff function call for non-standard site specific env variables people might want in channel finder

[kasemir]

How does IOCStats get the info? Maybe it only supports Linux, and maybe that's OK??

[tynanford]

Maybe it only supports Linux, and maybe that's OK??

We haven't introduced anything in reccaster so far, the environment_vars list only impacts recceiver. So if it is Linux dependent then it always has been.

I am a bit out of my element here, but maybe the OS dependent part is getting the full list of environment variables and not the getenv call. So maybe reccaster is OS independent as is. I guess either way the community seems fine with how it is.

https://github.com/ChannelFinder/recsync/blob/master/client/castApp/src/dbcb.c#L62

This is the IOC stats for ENGINEER:

https://github.com/epics-modules/iocStats/blob/master/iocAdmin/Db/ioc.template#L340
https://github.com/als-epics/iocStats/blob/master/devIocStats/devIocStatsString.c#L385

Sidenote, there also is a database DTYP for getenv from what I see here that I didn't know about before
https://epics.anl.gov/base/R3-15/4-docs/RELEASE_NOTES.html

[tynanford]

So stepping back, step 1 working meets your initial request for ENGINEER and LOCATION. I can see how having the hard coded envs list and also having the sendEnvVarToRecceiver functions could be confusing for someone new to recsync and just trying to get things working.

That means there would be 4 ways stuff gets sent to CF: "Standard" recsync fields (iocid, hostName, iocName), configurable INFO tags, configurable but limited set of env vars, and the new sendEnvVarToRecceiver function call for anything else

So we could,

• stick with the new environment_vars addition in recceiver. We could make a note with the list of available settings by default sent by reccaster. And then a specific site could manually edit the envs list in reccaster if they want other things sent
• stick with the new environment_vars addition in recceiver and also add the sendEnvVarToRecceiver function as an additional way to send information to channel finder. That could be nice to avoid having to re-compile reccaster and your IOCs
• Not use the new environment_vars addition and instead add the new sendEnvVarToRecceiver function and have that be the way to send data

Personally, I don't like option 3 as much since the envs hard coded list is already being sent to recceiver and removing it could break compatibility. And if we can't remove it and its already there, I feel like we might as well use it

[kasemir]

Well, there are certainly 3 ways: Standard recsync fields, info tags, environment variables.

Standard fields are just that.

Info tags are specific to a record. Good for "archive" or "alarm" settings, or to mark records for higher level apps. We could just ask the IOC person to add "info(ENGINEER, ...)" to each record, but I don't think that will fly.

Environment variables like ENGINEER apply to every record in an IOC. A relational database with "IOC" and "Channel" table would seem better to conserve storage, but then a no-sql database like elastic is faster when you want to allow additional properties.

It's good to have a predefined environment_vars.
Do you want to allow adding to that, or simply have a call to replace them:

# Replace default list of ENGINEER,LOCATION:
setRecsyncEnvironmentVars("CONTACT, BUILDING, RACK")

[tynanford]

setRecsyncEnvironmentVars("CONTACT, BUILDING, RACK")

I like this idea! Let me look into implementing that