Need to wrap Environment variables within /etc/systemd/system/starlink-influx2.service with " " about starlink-grpc-tools HOT 6 CLOSED

I'm no expert on systemd, but my brief testing (on Ubuntu 20.04 and 22.04) produced no problem with unquoted values with equals signs in them, and incorrect behavior when I quote the entire Environment= value.

My reading of the systemd.exec man page also suggests quoting the entire line is incorrect. It states the Environment= config option "Takes a space-separated list of variable assignments.", thus quoting the entire line will result in a single environment variable (the first one) being set with a value that includes the entire rest of the line after the first equals sign.

That same man page does suggest it is necessary to quote values with equals signs, though the only examples are for values that include spaces, not equals.

from starlink-grpc-tools.

Ok, this definitely means some more digging. Good point about the whole string ( " " ) being passed as a single variable. There must be a "good" way to pass environment variables without breaking the systemd convention. I wonder if escaping the = signs (or the entire variable) in single quotes is possible ... more to investiage

I have a question about why pass variables via the environment - why not directly pass them as though you are running the script from the command prompt?

ie:

/opt/starlink-grpc-tools/dish_grpc_influx2.py -T -B starlink -O -u 127.0.0.1:8086 -t 10 status alert_detail

from starlink-grpc-tools.

There must be a "good" way to pass environment variables without breaking the systemd convention. I wonder if escaping the = signs (or the entire variable) in single quotes is possible ...

The (somewhat convoluted) examples in the systemd man pages have each individual environment variable assignment quoted, which I think would be:

Environment="INFLUXDB_URL=http://localhost:8086" "INFLUXDB_TOKEN=<changeme>" "INFLUXDB_Bucket=<changeme>" "INFLUXDB_ORG=<changeme>" "INFLUXDB_SSL=false"

That syntax seems weird to me, and I would prefer to just quote the values, but since it works for me without any quotes, I don't have the ability to test whether or not that would fix whatever issue you're having.

I have a question about why pass variables via the environment - why not directly pass them as though you are running the script from the command prompt?

I didn't write this service config file, either, but I assume it was due to a perception that environment variables would be more secure than passing on the command line.

I suppose it is marginally better, given that command lines can show up in top and ps output, while pulling environment from other processes generally requires root privilege. However, the systemd.exec man page specifically warns against using the Environment= option to pass secrets, given that it's exposed on D-Bus without any protection whatsoever. That would be true for the command line args, too, of course.

from starlink-grpc-tools.

So... I just reread your initial report, and I think I know why you were having problems. While it's true that the systemd man pages say an equals in environment variables needs to be quoted, I don't believe that's the case in modern versions of systemd.

Rather, there problem is the following variable setting (which is also a problem in the checked-in example, which I will fix):

INFLUXDB_SSL=false

This does not do what you probably want and should just be removed. This will tell the script to use the file "false" as a CA root cert for SSL verification. You haven't specified an HTTPS URL, though, so the script is complaining about inconsistent options. The meaning of that environment variable is shared with the InfluxDB 1.x script where it made a little more sense, but the valid values are "secure", which is effectively ignored, "insecure", which is equivalent of -I command line option, or any other string, which is the equivalent of -C command line option. Whether or not to use SSL at all is determined by the URL.

I'm not entirely sure why putting quotes around the entire line worked for you. It would have stopped passing the INFLUXDB_SSL variable, thus would have avoided the specific error you were hitting, but I would have expected it to break things even worse....

Also:

INFLUXDB_URL=127.0.0.1:8086

I would recommend using a full URL (http://127.0.0.1:8086) here rather than a bare host:port. Whether or not a bare host:port will work may be dependent on what version of the InfluxDB 2.x Python client module you have installed. (Or maybe it has always worked, and I just got confused when looking into issue #49...)

from starlink-grpc-tools.

sparky8512, I super appreciate you explaining all of your findings to me, along with the discourse on some of the "whys" like the security concerns. Thanks for taking the time to investigate this thoroughly and explain everything along the way - it helps others (such as myself) to learn, and hopefully one day contribute more effectively.

from starlink-grpc-tools.

No problem. There was, after all, an error in the example.

Is there anything left to resolve on this issue? If not, please close it out.

from starlink-grpc-tools.