Define profiles via files

Hello all.

We have recently installed Open On Demand v3 in my team. We are “playing” and trying to understand the new capabilities, mainly the profiles, which will be very useful for our users.

Reading the documentation, my understanding is that profiles can be defined either in dashboard.yml or with separated .yml files in /etc/ood/config/ondemand.d

So, if I define the following block in dashboard.yml:

profiles:
  prof1:
    navbar_type: "light"

I get a profile with the navbar color light. This works perfectly.

I would like to know how I can do that via the files. Should I define a file called prof1.yml? Should the contents look like this:

prof1:
  navbar_type: "light"

or just the navbar line?

How should I invoke such file from the main dashboard.yml file?

profiles:
  - prof1.yml

Would this work? Am I missing something? I have tried several configuration combinations and unfortunately, I must be doing something wrong because none is working.

Thank you for your help.

Hello and welcome!

Looking at the docs, note that all the profiles are brought together into a single object in the end which are grouped by their names. So, the key sentence I think you need to focus on is:

To define profile properties, we have to group them under a profile name within the profiles keyword.

Which comes from the docs:
https://osc.github.io/ood-documentation/latest/customizations.html?highlight=profiles#configuration-profiles

So you will need that profiles keyword when you defined a profile in another file, that way all the profiles can be aggregated into the profiles object.

So your prof1.yml would need that profiles key to then hold the prof1 key itself and the values associated with it. Does that make sense? Please let me know if not and if you’ve hit other issues I didn’t address.

Hello @travert,

Thank you for the response. That makes full sense. I tested and it works.

I was expecting somehow that we needed to “invoke” such profiles in the dashboard.yml (i.e.: create the *.yml files and then list the ones you want in the other file; but now I’m thinking that such “filtering” is done with the creation of the menu to pick them, am I right? Because you may have 7 profiles defined but for some reason only want to show 4 of them).

I also realized that I was missing the correct permissions in the file. Are the permissions used to let people use a certain profile or not? Although I see that even if you cannot read a profile, it is sill shown in the drop-down menu.

Thanks again for your help!

Your question covers a lot of ground - so let me break it down:

  • Which profiles people can view

The system will read all the files it can in ondemand.d then merge them all. Recently we patched this so that the files are sorted by name before they’re read so you have some guarantees on the order in which files are loaded.

You can authorize certain profiles by making the files 640 permissions behind some group. So you can use FACLs to hide or show certain profiles to certain Unix groups.

  • how to invoke profiles.

You need to list all the available profiles in profile_links.

https://osc.github.io/ood-documentation/latest/customizations.html?highlight=profile_links#manual-profile-selection

Another variant of this is that you can use host based profiles and set several hostnames. In this variation - users will not choose the profile, but instead get shown the profile based of the hostname they’re using to access the site. So you could have 1 instance of OOD that serves multiple hostnames and toggles the display based on which hostname is being used.

Lastly - if you’re dealing with duplication as your initial topic suggests - you can utilize YAML anchors and aliases (within the same file I believe). Just search for YAML anchors and aliases in a search engine to see docs & blogs for the same.

Thanks for the explanation @jeff.ohrstrom.
The original question was related to the syntax of the .yml files.
Thank you for the reply. I think this question can be marked as resolved if you agree.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.