How to make groups from the CycleCloud (file) Server accessible to the Scheduler and Execute nodes?

Question

Hi,

I have a CycleCloud Server which is also configured as an NFS fileserver which presents home, data and apps directories via NFS to the CycleCloud scheduler and execute nodes.

It seems that CycleCloud adds users and groups to the scheduler & execute nodes when it initialises them for the users that are defined in the CycleCloud UI, but I need to copy across some additional (project data) groups from the CycleCloud server - so that users can see data in groups that is not their primary group that matches their uid.

How can I add/copy these groups from the CycleCloud server to the scheduler and cluster nodes? I am thinking it would need to be done via a cloud-init or cluster-init script, but the script running on the scheduler/execute nodes would not be able to remotely access the /etc/group file on the CycleCloud Server?

Answer 1

Hello Gary Mansell

Welcome to Microsoft Q&A Platform, thanks for posting your query here.

Based on your ask and and your environment, I checked with internal team on this and bet way is LDAP or AD.

It is not recommended using the VM running Cycle Cloud as home directory. Either use one of Azure’s hosted options or at least a separate VM with some kind of backup.

There is no need to copy anything, just manage users and groups via Cyclecloud UI and manage the secondary groups and permissions via cloud or cluster-init using usermod and ACLs.

This way the passwd and group under etc folder are the same in all the cluster nodes and you only have to worry about managing the secondary groups and permissions of those project folders.

You can also use an external LDAP server to manage all users and groups but that is not straight-forward.

You can certainly use CC’s user management but you will have to do all group assignment with it. This is not easy because you have to update all machines whenever there is a change. There’s no solution for using another machine’s /etc/group, for good reason, which is why using proper LDAP might be easier.

The alternative is to run some code on all machines when something changes, which is what CC does for users and the sudo privilege, but does not do for groups.

Hope this helps.