Avoid Changing Password of User

[jjathman]

What we would like to do is manage SFTPGo user accounts with Terraform but not change the password of the user at all. Is this possible?

Steps

1. Create new user account with Terraform
2. Either an administrator or the user modifies the password
3. Make other changes to the user account with Terraform but leave the password whatever value it currently is

If I don't specify the password in the sftpgo_user resource then it seems as though the password is removed from the user.

[MaxWinterstein]

Did you try some lifecycle properties to ignore changes?

https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle#ignore_changes

[jjathman]

@MaxWinterstein yes, that does prevent Terraform from detecting that the password has changed, however if I want to modify a property of the user after it has been created, for example change the permissions value, then the password ends up being changed. I believe it gets removed.

I believe it's because of this code:

terraform-provider-sftpgo/sftpgo/client/users.go

Lines 30 to 33 in eb34266

	// we remote the omitempty attribute from the password
	// otherwise setting an empty password will preserve the current one
	// on updated
	Password string `json:"password"`

[jjathman]

@drakkan I know your time is limited for issues like this. If we became a paying customer is this something that in theory could be looked into as a feature request?

[drakkan]

@jjathman thanks for considering supporting SFTPGo, but I think your motivation is wrong: you should support the open source software you use for ongoing maintenance, not just to add a new feature you need for your specific use case. If you are using or considering using SFTPGo now, it is because a lot of work has been done to provide you with a production-ready file transfer solution, and a lot more work is required to maintain and evolve it. If no one supports open source projects, they will no longer be maintained 😄

Providing support for an open source project is a matter of mutual trust, there is no expiring license that you are obligated to renew.
We do not provide one-time support, upon request, we expect our customers to sign up for a long-term support plan, we don't provide support to companies that subscribe/unsubscribe each time they have a question/issue.
We have limited time and energy and prefer to dedicate it to users/companies who recognize our commitment to creating and maintaining SFTPGo.

That said, we do of course give higher priority to requests from paying customers, but that doesn't mean we'll add everything a paying customer ask for. Feature requests must fit the scope of the SFTPGo open source project. We sometimes provide custom plugins for very specific use cases to our Enterprise subscribers.

The Terraform provider was added because useful to one of our Enterprise plan subscriber. To be honest, I have never used Terraform before writing this provider so I may miss something here, for what I know the password is stored in the Terraform state. It looks like you are trying to use Terraform as a PATCH style REST API.
Please provide more details about your use case, for example the steps you are using to create and update your users. I may not reply here, but I will consider it.

Of course feel free to contact us to our the dedicated email address if you want discuss about a support plan. Thank you

[jjathman]

@drakkan thank you for the thoughtful response and I do agree with everything you said.

Little more context is that we just started using your product a week ago and while it seems very promising I think we are at more of an evaluation stage. One of the features we value highly is automation with our tools so the terraform provider was exciting to see!

Our use case is where we would like to use automation to create and maintain users (and all other settings) but ideally we would allow end users the ability to change their passwords if they so choose. However I think the current version of the terraform provider would not allow that since it would change the password back each time terraform was run. Does that make sense?

Sorry for implying we wanted to pay for support for a one time issue. We are definitely interested in a long term plan. I was just unsure if this is the kind of change that is something you’d even consider making.

Thank you again. You’ve created a wonderful product!

[drakkan]

Users can also change public keys, email address etc., not just password. Anyway, please read the following posts

https://www.reddit.com/r/Terraform/comments/17jtxcd/can_import_add_new_properties_to_a_resource/
https://stackoverflow.com/questions/43950097/how-to-import-manual-changes-into-terraform-remote-state

[jjathman]

Thanks, and those are good points about all the other user editable fields. I hadn’t considered them but you are right they would have the same problem.

As that Reddit post talks about terraform assumes it is in control of any properties and resources it knows about and will always try to get them back to the state it wants them to be in. One can import resources initially if they were created outside of terraform, however from that point on TF will want to manage them.

In this case maybe a potential solution would be to create separate resources that split off the user editable information from the details controlled by an administrator. So in my case I want to manage the GCS setup and permissions but not the email or password or public keys. But as it currently is implemented these are all one TF resource so they all have to be controlled or none controlled by TF.