Hi folks,

I've got a high performance computing (HPC) use case that will need AD integration for user identity management. We've got a working IPA server in AWS that has 1-way trusts going to several remote AD forests and child domains. Works fine but so far all of the enrolled clients are largely static/persistent boxes.

The issue is that the HPC cluster footprint is going to be elastic by design. We'll likely keep 3-5 nodes in the grid online 24x7 but the vast majority of the compute node fleet (hundreds of nodes quite likely) will be fired up on demand as a mixture of spot, RI and hourly-rate EC2 instances. The cluster will automatically shrink in size as well when needed.

Trying to think of which method I should use for managing users (mainly UID and GID values) on the compute fleet:

[Option 1] Script the enrollment and de-install actions via existing hooks we have for running scripts at "first boot" as well as "pre-termination". I think this seems technically pretty straightforward but I'm not sure I really need to stuff our IPA server with host information for boxes that are considered anonymous and disposable. We don't care about them really and don't need to implement RBAC controls on them. Also slightly worried that a large-scale enrollment or uninstall action may bog down the server or (worse) perhaps only partially complete leading to an HPC grid where jobs flow into a bad box and die en-mass because "user does not exist..."

[Option 2] Steal from the HPC ops playbook and minimize network services that can cause failures. Distribute static files to the worker fleet -- Bind the 24x7 persistent systems to the IPA server and force all HPC users to provide a public SSH key. Then use commands like "id <username" and getent utilities to dump the username/uid/gid values so that we can manufacture static /etc/passwd, /etc/shadow and /etc/group files that can be pushed out to the compute node fleet. The main win here is that we can maintain consistent IPA-derived UID/GID/username/group data cluster wide while totally removing the need for an elastic set of anonymous boxes to be individually enrolled and removed from IPA all the time.

Right now I'm leaning towards Option #2 but would love to hear experiences regarding moderate-scale automatic enrollment and removal of clients!


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to