grafana role improvements?

[ph1l]

TASK [grafana : Change admin password] *****************************************
fatal: [marinepi]: FAILED! => {"failed": true, "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'grafana_admin_password' is undefined\n\nThe error appears to have been in '/home/elektron/code/marinepi-provisioning/roles/grafana/tasks/main.yml': line 38, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Change admin password\n  ^ here\n"}

[tkurki]

Not really - you need to specify that. I didn't want to specify a default one.

Not sure how this should be documented in a user friendly manner.

[ph1l]

hmm.. when I tried it it was putting settings in the wrong place in the file. I re-wrote part of it to do a few things..

use ini_file because it handles ini_files correctly.

use openssl to generate a random secret_key and only set it once

etc...

[tkurki]

If you randomize the secret key reprovisioning will invalidate stuff in your browser - I'd prefer to keep it valid.

ini_file: never heard, I am not the greatest Ansible expert. Looking forward to PR on that!

[ph1l]

it randomizes it just once, by touching a file that allows ansible to skip it next time.

[tkurki]

Not just reprovision-Grafana, but reprovision-from-scratch use case.

[ph1l]

reprovision from scratch? I'm unsure what you mean. It doesn't sound possible without writing an equivalent un-provision script to remove packages, revert system config files, etc..

[tkurki]

From a base Raspbian image.

[tkurki]

I mean, install everything from scratch.

[ph1l]

looks like the secret_key is used for signing cookies: https://github.com/grafana/grafana/blob/6af62abd41c4f2b752772a9b816d4c68b734ef28/docs/sources/installation/configuration.md#secret_key

So my changes would re-generate the secret key on the first (or next) pass through the grafana role, invalidating 'keep me signed in' and 'remember me' cookies that happen to already exist. Subsequent runs would skip the generation due to the touch file.

It doesn't appear to have anything to do with saving dashboards or user's passwords. I was even able to stay logged in through a regeneration of the secret key, it didn't effect my current session.

I suppose I could actually write out the generated secret to the "touch" file. That would make the setting persistent in the case of a wiped config file.

The design choices of the automation depend on the use cases. Since I just installed for the first time, perhaps I don't understand all the use cases. The more rigid way to design this role, would be to generate the grafana config file from a template, then we could guarantee the state of it. However, that would increase the maintenance cost of the role and limit the customization a user could do outside of ansible.

I guess we should ask ourselves, is the idea of this automation to fully manage the server and provide a rigid platform that we're trying to make reliable and upgradeable or are we providing a quick start launching point to get a server up and running and then the user is supposed to start managing it themselves?

Cheers :-)

[tkurki]

I think we can eat & save the cake: if grafana_secret variable is defined use that, otherwise generate a random one. What do you think?

I created this project with "immutable server" in mind: there should be nothing valuable on the SD card - if it corrupts I can reprovision a fresh image and be good to go. And don't need to hassle with manual upgrades.

Another, more distant goal is to possibly use this as a way to create a distributable SD card image with a documented and sort of repeatable (subject to upgraded dependencies) provisioning process, so that I could point to these scripts when people ask what is on the image and how it was created.

[ph1l]

The grafana_secret being override-able makes sense to me. I'll take a stab at that later and resubmit a cleaner PR.

Hmm, An immutable root partition would be neat, but would need careful design. It would either exclude certain features or require a writable partition somewhere (thumb drive?) for influxdb data or perhaps other things.

I like the idea of distributing a pre-built image too. this would make it much easier for people to deploy a signalk pi in a reproducible way. the thumb drive could contain config files and data files (anything unique to a particular installation,) and allow the core software and device to be more of a black box. It's basically a release technique that other commercial products use for firmware.

Just have to find a way to pay for the bandwidth of providing hundred MB downloads available to the public. Perhaps using OSTree to distribute atomic updates to the system maps well to this project?

https://ostree.readthedocs.io/en/latest/