I’m not sure if this is even something that’s even possible, but figured I’d ask.
Because of an NFS limitation on one of our storage appliances, the storage can only see the first 16 groups that a user is a member of. In interactive SSH sessions, we work around this by setting the primary group to be one the one of the directory we want to access. A user will do ‘newgrp groupA’, then be able to cd /projects/groupA. Otherwise, they’ll get a permission denied.
Is there any particular setting or environment, or ruby code that can be used so that when a user either changes directory in the web interface, or maybe when project areas in the Files dropdown are enumerated that a newgrp can be issued or a primary group set for access?
Hey, sorry for not replying sooner. Yea it’s not possible at the moment because the Per User Nginx starts with uid/gid pair. We’d have to restart it under a different gid for every different filesystem.
Hi, sorry for the delay, I’ve been out for awhile. Unfortunately the workaround still has some issues and I don’t think we can completely rely on it, but what we were looking at doing was modifying our sssd configuration to only resolve certain groups.
In the sssd.conf file we added:
ldap_use_tokengroups = false
ldap_group_search_base = dc=example,dc=com?sub?(|(cn=cluster_*)(cn=whateverothergroup))
Then when the users logged into the system they only saw group memberships that matched the search. Slurm, however, was having an issue where new users added to groups weren’t able to be found even though the underlying OS was ok with it.
So, I’d like to bring this up again (slightly). @jeff.ohrstrom , how does the PUN get the UID/GID info? If I wanted to change the primary GID that was being used to launch the PUN, where would I start looking for that?
I’m not necessarily looking for something selectable, but if I could change a users default GID before launching the PUN, that might take care of some of the issues I’m forseeing.
I’m definitely not a Ruby programmer, but I’m looking in /opt/ood/nginx_stage/lib/nginx_stage/user.rb and something in here-ish:
# @param user [String] the user name defining this object
# @raise [ArgumentError] if user or primary group doesn't exist on local system
def initialize(user)
@passwd = Etc.getpwnam user.to_s
@group = Etc.getgrgid gid
@groups = get_groups
end
# User's primary group name
# @return [String] the primary group name
def group
@group.name
end
I’m thinking kind of something similar to what I did in the dashboard initializer, like:
projects = User.new.groups.map(&:name).grep(/^cluster_./)
and some how replacing @group.name with the returned one, but I really am not sure how to do this right.
Yep, redefine that def group function and you may get it.
Though you’ll have to modify the nginx_stage source code itself - a dashboard initializer is too late because we’re starting nginx as this user:group and nginx then boots everything else.
Here’s the relevant nginx configuration template where we’re telling nginx to startup as this user:group.
This may work for you. I’m just using @groups here and first to just get one (you’re dealing with an array here) and the || gives a little safety if there is nothing found, it returns the default.
def group
@groups.map(&:name).grep(/^cluster_./).first || @group.name
end
The groups.map line gave an error: Error – undefined method `name’ for ‘domain’:String (domain is the first part of the group name Domain Users)…on a side note, it looks like the get_groups line won’t like group names with spaces, but hasn’t seemed to really be an issue so far.
I did this instead, but it doesn’t have the safety net if the group isn’t found.
def group
groups.each do |groupitem|
if groupitem.start_with? “cluster_” @realgroup = groupitem
end
end @group.name = @realgroup
end
argh. I think it’s a deeper issue. Yes, I got the nginx piece to start up with the correct group, but basically all functionality of ondemand is still running as the ‘domain users’ group (file creation, job submission, etc), and I think it stems from the Passenger watchdog process. If that process were started up with the desired group, I think the rest would just inherit.
That line works. The passenger app though does still seem to be running under the default group. Nginx does not. I’m checking this by looking at the /proc/pid#/status entry and seeing what the ‘Gid’ lists as the first id. So something with the way passenger gets kicked off is not inheriting…ultimately this might be too hard to pin down.
that’s what I get for copying.