Use provider to configure /settings/general?

[ionlights]

Is it possible to have this provider (and the other *arr providers) configure the "General Settings"? (At /settings/general.)

[Fuochi]

Hi @ionlights, I haven't implemented this feature yet. Mainly, the reason behind it is that the API key is a requirement for the provider, and via settings you can edit that parameter. Still, would you like this feature? I can include something in the next release.

[ionlights]

👋 @Fuochi – I see. Perhaps that’s something that’s listed primarily as a warning?

Ideally, /settings/general could be both a data source and a resource? This way you can configure other settings while maintaining the API key.

… would you like this feature?

Definitely! 🙂 (I can open similar issues across the other relevant *arr providers as well, if helpful.)

[Fuochi]

Ok, I'll try to find the time to add this feature in the next few weeks. No worries about the other providers, I'll cross reference the issue, no big deal.

[ionlights]

Awesome! Thanks. 🙂

[Fuochi]

Hi @ionlights, This should be now live in v2.0.0. I'll wait for your feedback before propagating the resource to other providers. Be careful, there are few breaking changes

[mscreations]

I am hitting an issue with this for authentication. I have this snippet in my terraform file:

authentication = {
  method = "basic"
  username = data.sops.secrets.data["arr_user"]
  password = data.sops.secrets.data["arr_pass"]
}

I get an error:

When applying changes to radarr_host.radarr, provider
 "provider[\"registry.terraform.io/devopsarr/radarr\"]" produced an unexpected new value:
 .authentication: inconsistent values for sensitive attribute.

I've also tried hard-coding the password and also creating a sensitive variable to attempt to fix it, but still get the same error.

[Fuochi]

my bad, Radarr doesn't send back the password in clear text as it is sent from user. It's encrypted and only an hash is sent back. I have to think a bit on how to handle this properly.

[mscreations]

It looks like Radarr returns the the sha256sum of the password. Is there a way to compute that and compare against what is returned by the Radarr API?

[Fuochi]

That is what I was trying to figure out. But I don't think there is. For now, I'm thinking either to add a boolean field update_secrets, which will update the secret when set to true (but that will break the idempotency), or to create a read only field which contains both the encrypted string and the actual password value, which will help us manage the state. I'll have to try the second one to check if it's feasible

[Fuochi]

@mscreations of course if you have any suggestion/preference feel free to post them, every bit of help is always appreciated!

[Fuochi]

After a bit more digging, it seems the password is hashed and salted since last week: https://github.com/Radarr/Radarr/blob/15a4c3b742c8ca1567de81d7ebf7e62779426b7c/src/NzbDrone.Core/Authentication/UserService.cs#L125-L142 Before that, it was only hashed. Still, it doesn't change much for us. It means we can't dechipher the string ourside. I added a new read only field to write the hashed password in the state in #216, available in v2.0.1. It should be enough to make this work, could you please check if it's ok?

[mscreations]

Seems to be working okay for me.

[Fuochi]

cool! Thanks for confirming @mscreations! I'll propagate this to the other providers as soon as I find some time!

[Fuochi]

done for every provider except whisparr. waiting to do that once it'll be refactored for the new version