We are very new to Open OnDemand and are hoping to introduce our users with our first implementation soon. We are a multi-cluster environment where all users get access to cluster1 and only some users getting access to cluster2 (names changed for convenience). Users of cluster2 will generally only use cluster2 but I don’t want to stop them having the opportunity to use cluster1. The two clusters do NOT share home or scratch.
I have configured both clusters on our OOD server and if a user does not have access to cluster2 it remains hidden from them. Which is great and just the way we want it. I have configured MOTD/quotas to only display cluster2 MOTD/quotas if the user has access to cluster2 (done by using groups).
I can do the same for the different file systems for the File menu. However for cluster2 users I would like the File menu to list all cluster2 file systems first. For all users I would prefer not to have a “Home Directory” at all but simply list all file systems as named systems. e.g.
For a cluster1 user the File menus would be:
cluster1 Home
cluster1 Scratch
While a cluster2 user would see:
cluster2 Home
cluster2 Scratch
cluster1 Home
cluster1 Scratch
I could see how I could override some of this with files:
/etc/ood/config/apps/dashboard/initializers/oob.rb
/etc/ood/config/apps/dashboard/views/files/_favorites.html.erb
I think to complete the customisation I would also need to modify:
/var/www/ood/apps/sys/dashboard/app/apps/ood_app.rb
Is there a better more supported way to achieve want I would like?
Thank you for your work on Open OnDemand. Very impressive.
Cheers.
–JohnM
I think you’re on the right track. I don’t think what you want is supported out of the box, as in HOME always gets shown in that favorite menu.
Do not modify anything in /var/www/ood/apps. If you need to change the behavior of ood_app.rb do so in an initializer. In the ruby on rails world they call this ‘monkey patching’.
In an initializer that you have in /etc like ood.rb you can define (redefine) this class and rewrite the behavior.
We still have this patch hanging around on our systems.
The /etc and /var distinction is important because things in /var will be overwritten with every update, while things in /etc will never be overwritten with updates.
Thank you Jeff for your advice and confirming that modifying anything in /var was not the way forward.
Note I am very new to ruby and so the following is probably obvious to those with more experience than me.
I was hoping to be able to just override ‘def links’ in the class OodApp but everything I tried just caused errors and a crashed web page. In the end I did the following.
cp /var/www/ood/apps/sys/dashboard/app/apps/ood_app.rb /etc/ood/config/apps/dashboard/initializers
modify def links in /etc/ood/config/apps/dashboard/initializers/ood_app.rb keeping all other defs.
The new def links now looks like:
def links
if role == "files"
username = Etc.getlogin
is_cluster2_user = Etc.getgrnam( 'cluster2_group' ).mem.include?( username )
# assumes Home Directory is primary...
[
if is_cluster2_user
OodAppLink.new(
title: "cluster2 Home",
description: manifest.description,
url: OodAppkit::Urls::Files.new(base_url: url).url(path: "/cluster2/home/#{User.new.name}" ),
icon_uri: "fas://home",
caption: caption,
new_tab: open_in_new_window?,
tile: tile
)
else
OodAppLink.new(
title: "cluster1 Home",
description: manifest.description,
url: OodAppkit::Urls::Files.new(base_url: url).url(path: Dir.home),
icon_uri: "fas://home",
caption: caption,
new_tab: open_in_new_window?,
tile: tile
)
end
].concat(
# the remaining code in def links is unmodified from this point
There has been little testing for this modification so may have some other unintended consequences.
Cheers.
I now realise I will also need to set $OOD_DATAROOT depending on whether the logged in user wants to use cluster1 or cluster2. Would it be possible for a user to select their preferred cluster and have $OOD_DATAROOT set appropriately? Perhaps with profiles?
Unfortunately we don’t have good support for multi-cluster HOME’s right now. If all the clusters share the same HOME it’d be different - but as it is you may have to deploy an entirely separate web stack for your separate clusters.