- HPC Buyers Guide
Detailed Buyers Reference- Applications
- Budget
- Processors
- Interconnects
- Memory
- Distributions
- Cluster Management
- Warranty and Support
- Cluster Racking
- Cluster Logical Layout
- Master Node
- Storage
- Backup
- Nodes
- Power
- Cooling
- Commercial Software
- Schedulers
- Security
- Windows Integration
- Shipping and Delivery
- On-Site and Training
- Next Steps
HPC Applications- Processor
- System
- Network
- Storage
- Power
- Cooling
- Facilities Estimator
- Remote Management
- Green Computing
- Visualization
- Compilers
- Operating Systems
- Schedulers and Tools
- Virtualization
Account Management
What are your account management options?
By default, Aspen delivers your cluster with a standard simplified user schema based on password, shadow, and group files on the master node(s). After adding a user on the master node using standard distribution tools such as “useradd”, executing an Aspen supplied script called “authcopy” propagates the user information to all other nodes in the cluster.
Aspen clusters are configured for host-based authentication between all cluster nodes by default, so any user account that exists on the master node is automatically allowed to log into any node that has that same account. The user password, ssh keys, authorized_keys file, and .rhosts files are not checked, so the user can change their password on the master node(s) at any time without affecting any node connectivity within the cluster.
In normal cases, “authcopy” does not need to be ran after every user password change. If other externally accessed nodes exist in the cluster, password changes can be aliased to automatically perform an “authcopy” after each password change is successfully completed so that any other nodes a user might log in to from outside the cluster immediately receives the new password.
Removing a cluster user is just as simple. Utilize the distributions command, such as “userdel” to remove the user, then run “authcopy” again. The user is removed from every node in the cluster.
Some organizations may operate single sign-on or centralized user management mechanisms such as LDAP, Kerberos, or Network Information System (NIS) which are used to authenticate all users in your organization. Your cluster nodes may be configured to access an external server for user authorization in this case, but slow performance or reliability issues on your organization servers may affect code execution speed or reliability on your cluster.
Secondary or slave servers can be configured on your master node(s), however, Aspen cannot perform this configuration for you without interaction with your organizational user administrators. Extensive coordination between your organization user administrators and Aspen engineering will be necessary to successfully deploy your site specific user authorization schema, and final integration may only be possible after your cluster is installed in its final location.
