Accept GID and UID as optional parameters for elasticsearch class

[sandeepkanabar]

Feature Description

We usually want the same UID and GID on all the nodes. This is a must if we make use of Elasticsearch's snapshots wherein snapshot created by a node are stored on NFS and accessed by another node. Without the same UID/GID, it will result in permission denied.

Considering this, can we make the elasticsearch class accept GID and UID as parameters?

[tylerjl]

I think I understand what you're asking, but I'm unsure whether it's feasible to do. Reasoning:

Right now the module doesn't handle elasticsearch user creation and management at all; that's left up to the package manager (apt, rpm) on the system. This would be easy to resolve if we could just change the IDs with usermod/groupmod, but the Elasticsearch package sets file ownership in several spots as part of the post-installation steps. In order to make the UID/GID change safe we'd need to do something like a find / -uid <old> -exec chown <new> and somehow make it idempotent and not absurdly expensive to run each time.

I'm also unsure how changing UID/GID values would effect the packages' post-uninstallation steps, though those are probably safer (i.e. they probably delete by name).

With that being said, the module does control the minimum necessary files to run the instances, so if you wanted to do this in your particular environment, you could do something like this (IDs are arbitrary):

user { 'elasticsearch':
  uid    => 700,
  after  => Class['elasticsearch::package'],
  before => Class['elasticsearch::config'],
}

group { 'elasticsearch':
  gid    => 701,
  after  => Class['elasticsearch::package'],
  before => Class['elasticsearch::config'],
}

It isn't perfect, and you'll probably have orphaned directories in a few places, but because the module only reference users and groups by their canonical names instead of IDs, it should (?) work.

[sandeepkanabar]

Thank you very much @tylerjl for the detailed clarification. I'm doing exactly what you suggested but reading this post got me thinking that everyone else is doing the same too. So I wondered why not parameterize it and save everyone from writing those two blocks of code. But I agree - in order to make it failsafe, there are some caveats as you listed.