Comments (6)
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.
Related Issues (20)
- TypedDicts have type Any in IDE HOT 5
- no attribute 'wedge_abs_fraction_obstructed' HOT 5
- Make robust against field removal in grpc protocol HOT 2
- Error in "Running with SystemD" instructions HOT 2
- Make work on arm64 (aka Raspberry Pi) HOT 15
- Docker image missing generated gRPC protocol modules HOT 3
- Did Starlink disable the gRPC/web interface? HOT 2
- Remote API HOT 6
- Zabbix Template for Starlink Dishy HOT 3
- wifi_util.proto missing HOT 1
- Unknown Alert code 384 HOT 2
- MessageFactory class is deprecated HOT 3
- Is it possible to poll RSSI values? HOT 2
- is it possible to query satellite coordinates from the gRPC interface? HOT 1
- How does the Bandwidth usage works ? HOT 12
- Obstruction map - which way is "up" ? HOT 2
- Get sleep mode status? HOT 6
- Docker image: Failed writing to InfluxDB HOT 2
- Check for and trigger software updates HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from starlink-grpc-tools.