Secondary linux group for interactive app launching (login seems resilient)

We have, as I’m sure is not uncommon, people prevented from launching interactive apps because their group quota is exceeded, often by others in the group.

I have seen from earlier topics (Using newgrp that the nginx/pun is tied to the uid/gid that was used, iiuc, to signin to ood. I believe that the resolution here would be to use our account management system to change the primary linux group affiliation, signout of any existing ood dashboard sessions, and sign back in with the ‘new’ primary linux group.

Is there any method to adapt an ood session on-the-fly to use an alternative gid to allow the work to continue, while the usual tussling amongst group members plays out?

1 Like

A thousand apologies for the delay.

I don’t believe there’s anything we can do here once the PUN has started it’s started with the groups it had.

That said why do you have a strong reliance on the primary group? Can’t the user just start submitting jobs under a different secondary group?

My own apologies, Jeff – I was away last week.

We have hard quotas in effect, that in our implementation, preents writing the app files under ~/ondemand/data/sys/dashboard/batch_connect/sys/bc_desktop/markov/output/… fail to write because the primary linux group permissions are in effect for writing to disk.

Often, it takes time for group members to recognize the problem, and to coordinate their response. If a person could proceed under a secondary group, that would seem to be useful.

I could be approaching the situation from too limited a perspective – e.g. we should be organizing our relation between researchers and storage differently. Open to suggestions on how to place the resolution to this problem directly in the hands of the researchers.

Thanks

Got it. Thanks. Yea changing home directories is going to be tough.

I’d suggest instead utilizing this feature which will create warning banners when you’re disk is about to fill up. This way you can give them a You're at 90% utilization type warnings so they can be aware.

https://osc.github.io/ood-documentation/latest/customization.html#disk-quota-warnings-on-dashboard

I don’t know how we pull this information but can make inquires, but essentially you’d drop a json file somewhere that has quota information and we’ll show the banner if a users’ quota object is less than some configurable threshold.

Thanks, Jeff – This looks like a good way to go. It would keep the quota situation front and center for those reliant on ood, and the messaging would allow us to direct students/researchers to work together to manage the quota.

Cheers