Open WaleedNaveed opened 4 years ago
Hi,
Please see This Project is Dormant – explains why all the IOTstack activity is occuring at SensorsIot/IOTstack.
If I understand what you are saying, you are expecting a Dockerfile ENV variable to wind up in influxdb.conf.
I could be wrong but I really don't think environment variables work that way, irrespective of the context.
In the case of a Dockerfile ENV
statement, I think that's a way of passing something to a later step in the Dockerfile.
Suppose your Dockerfile was compiling your C# code and you wanted to have conditional compilation based on whether
INFLUXDB_HTTP_AUTH_ENABLED
was true or not. I think you could use it for that but not for getting something into influxdb.conf unless you did something like you are doing withTZ
.
More generally, if you set an environment variable in either of the following:
~/IOTstack/docker-compose.yml
~/IOTstack/services/influxdb/influxdb.env
those still don't wind up in influxdb.conf. Variables set that way are just "available" to processes inside the container as they are launched. The process still has to check.
Hold that thought. I'll come back to it.
On the topic of timezones, I have had zero luck getting Influx to respect a timezone set globally.
If you find a way to make it work then please let me know.
Here is what I do. Step 1 is an alias defined in ~/.profile
alias influx='docker exec -it influxdb influx -precision=rfc3339'
With that in place, I can get into the Influx CLI just by typing influx
. If I want to pass additional arguments then I can tack those on the end, like this:
$ influx -database power
One of the measurements in the "power" database is called "hiking" (the name of the electricity meter). It is logging grid voltage every 10 seconds. Assume my time is 09:40 on Sept 17 2020, and my time-zone is UTC+10. If I query like this:
> select voltage from hiking where time > '2020-09-17T09:40:00+00:00'
I get an empty result set - because 09:40 at UTC+0 is 19:40 UTC+10 and hasn't happened yet. If I set the time-zone offset to UTC+10 in the query:
> select voltage from hiking where time > '2020-09-17T09:40:00+10:00'
time voltage
---- -------
2020-09-16T23:40:07.642018568Z 246.9
I get a result but the timestamp in the time
column is UTC+0 (ie 10 hours behind my wallclock time). If I want to see the timestamp in my local timezone, I have to query like this:
> select voltage from hiking where time > '2020-09-17T09:40:00+10:00' tz('Australia/Sydney')
time voltage
---- -------
2020-09-17T09:40:07.642018568+10:00 246.9
When I examine the log from the influxdb container via:
$ docker logs influxdb
I see queries like the one below coming from Grafana. If I copy-and-paste the query:
> SELECT max(voltage) FROM power.autogen.hiking WHERE time >= now() - 6m GROUP BY time(30s)
time max
---- ---
2020-09-16T23:47:30Z 246.1
it seems to me that Grafana is getting back UTC+0. It draws charts in local time so it must be doing that conversion work itself.
Unlike the InfluxDB environment file, the Grafana environment file does contain a TZ:
$ head -1 ~/IOTstack/services/grafana/grafana.env
TZ=Australia/Sydney
but I have not experimented to see whether that is what Grafana actually respects, or if it is getting the information from the browser.
Returning to the topic of InfluxDB environment variables, back in June I did a bit of a deep dive into the topic of which environment variables "worked" (appeared to have an effect) versus those that didn't. I had intended to work towards a PR to document some how-to but got side-tracked onto other things.
Where I got to was this. First, you'd need to go into Influx and either use
an existing database or create
then use
a new one:
$ influx
> CREATE DATABASE "mydatabase"
> USE "mydatabase"
Then you define an administrative user:
> CREATE USER "dba" WITH password 'supremo' WITH ALL PRIVILEGES
plus some garden-variety users:
> CREATE USER "nodered" with password 'nodered'
> CREATE USER "grafana" with password 'grafana'
then set up the access rights:
> GRANT WRITE ON "mydatabase" TO "nodered"
> GRANT READ ON "mydatabase" TO "grafana"
Next, you drop out of the influx CLI (either Ctrl+D or exit
). Then you edit the InfluxDB enviroment file to set INFLUXDB_HTTP_AUTH_ENABLED
true:
$ grep "INFLUXDB_HTTP_AUTH_ENABLED" ~/IOTstack/services/influxdb/influxdb.env
INFLUXDB_HTTP_AUTH_ENABLED=true
and then you put it all into effect by "upping" the stack.
You don't have to "down" the stack first; what "up" does is cause docker-compose to notice changed environment files and recreate the affected container(s)
$ cd ~/IOTstack
$ docker-compose up -d
Recreating influxdb ...
Recreating influxdb ... done
Now, look at what happens if I try to access two different databases (the example "mydatabase" and a pre-existing "power" database):
$ influx
Connected to http://localhost:8086 version 1.8.2
InfluxDB shell version: 1.8.2
> use mydatabase
ERR: unable to parse authentication credentials
DB does not exist!
> use power
ERR: unable to parse authentication credentials
DB does not exist!
> auth
username: nodered
password:
> use mydatabase
Using database mydatabase
> use power
ERR: Database power doesn't exist. Run SHOW DATABASES for a list of existing databases.
DB does not exist!
> auth
username: dba
password:
> use mydatabase
Using database mydatabase
> use power
Using database power
Summary:
Some inferences I take from all this (which are probably fully documented somewhere in the InfluxDB doco):
create
a user without first "using" a database, users are global rather than per-database.INFLUXDB_HTTP_AUTH_ENABLED
true is how security is implemented. If it is false, all enforcement goes away (a handy thing to know if you lose passwords).INFLUXDB_HTTP_AUTH_ENABLED
applies to both CLI access and access by other processes like Grafana.With security enabled, there are a couple of ways of speeding-up your daily activities. You can pass the dba username and password on the end of the influx alias:
$ influx -database mydatabase -username dba -password supremo
or you can set two more environment variables:
$ grep "INFLUX_" ~/IOTstack/services/influxdb/influxdb.env
INFLUX_USERNAME=dba
INFLUX_PASSWORD=supremo
Those two variables are not some kind of general-access credentials that apply to everything. They are synonyms for the -username
and -password
parameters on the influx
CLI command. You can invoke the influx CLI command like I do with an alias, or more explicitly by using the right-hand-side of the alias:
$ docker exec -it influxdb influx -precision=rfc3339
or by starting a shell into the InfluxDB container and then invoking the CLI from there:
$ docker exec -it influxdb bash
# influx
>
Whatever your approach, those username and password environment variables only apply to starting the CLI.
I hope this helps.
@WaleedNaveed I just wrote a gist that includes all of the above.
If your question has been answered I'd appreciate it if you could remember to close this issue.
I am working on a C# application with InfluxDB and Grafana. I am using InfluxData.Net (https://github.com/pootzko/InfluxData.Net#createdatabaseasync). I have to create a password protected Influx database. My code is:
Issue is that when i go to Grafana on the server and add new data source with this database, data source works fine and does not show any error regarding username/password. Even the data in the database is shown in the grafana. I am using InfluxDB image. I have also tried to enable INFLUXDB_HTTP_AUTH_ENABLED in DockerFile of InfluxDB. My DockerFile is:
When i run the image created from this DockerFile, i don't get INFLUXDB_HTTP_AUTH_ENABLED entry in influxdb.conf file. As per InfluxDB documentation, setting INFLUXDB_HTTP_AUTH_ENABLED in environment variable will enable the authentication on the influx server but, in my case its not working.
How can i make a password protected influx database through influxDB image ? What can be the possible issue ? I am stuck and unable to create the password protected database. Any help would be much appreciated.