Home Directory customisation for multi-cluster

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

Hi and welcome!

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.

1 Like