Category: Open Source

Berlin, Friday 17 June 2022, it is 12:50 pm when I enter the Wikimedia Deutschland building for the first in-person meeting of the Movement Charter…

How Australian universities can use time-saving Drupal modules to deliver excellent digital experiences with minimal developer involvement. 

by
griffyn.heels
/ 14 July 2022

We work with several leading Australian universities that use Drupal to engage and attract current and prospective students. 

These unis experience similar problems:

• Small digital teams with lean budgets
• Vast amounts of content and digital real estate
• A highly competitive environment
• Increased pressure and focus on their digital presence
• The need to attract more international students

So, which modules do we recommend our higher education clients use to address these problems?

Layout Builder

Layout Builder is our most frequently recommended module for universities.

It provides editorial flexibility and control over complex page designs without ongoing developer involvement. Once configured, content authors have a suite of layouts and components–freeing them from strict templates. 

We also recommend giving the out-of-the-box experience a polish. Customising labels and help text makes it easier for newbie Drupal editors and users to maintain complex and exciting landing pages.

It’s worth noting that Layout Builder’s user experience is constantly improving, thanks to a community of contributors. In an upcoming blog post, we’ll share recommendations for the additional modules you should use, plus custom code for an exceptional user experience. 

Technical Insights

This approach can be rolled out in stages across individual content types even after a site is launched using an alternative editorial system such as Paragraphs. 

Layout Builder in action: a client case study

University of Queensland’s Future Students content hub

We developed reusable components for the University of Queensland (UQ) content and marketing teams. These ready-to-go pieces included the hero with several editable elements, tiles that link to other content, and an icon grid with prebuilt icons for consistency.

Each component can be reordered and edited in real-time with a preview. The good news is that content editors can also chop and change these parts with minimal Drupal CMS experience. 

For a more targeted experience, users can change seamlessly between domestic and international content based on their student type.

Content Hierarchy

The Entity Hierarchy module makes it easier for editors to use and organise content, creating more straightforward navigation for users.

It’s not unusual for universities to own over 20,000 individual pieces of content or ‘nodes’, including pages, blog posts, course listings and event pages. How that content is stored and retrieved is critical to the site’s overall performance, and that’s where Entity Hierarchy plays a vital role.

Technical Insights

University site IA is typically modelled in a content hierarchy and presented to the user with components like a sidebar menu. The Content Hierarchy module is designed to retrieve current page positions and its ancestor, descendant and sibling pages in the most performant fashion using a ‘nested set’ data model.

Content Hierarchy in action: a client case study

Charles Darwin University’s Research Institute for the Environment and Livelihoods

Charles Darwin University (CDU) supported the extension of Entity Hierarchy’s functionality further to create microsites within their CMS. 

The microsite sub-module designates one page as the ‘microsite homepage’. This homepage can have a secondary navigation bar, unique logo and title elements. Each microsite then inherits all the styling and existing CMS functionality without the overheads of maintaining a separate Drupal site.

As a result, maintaining and monitoring a suite of Drupal properties becomes much more manageable for smaller teams.

Resource recommendations

The Backfill Formatter module automatically suggests recommended content to users based on its similarity to other content. 

This automation saves content editors time and ensures there’s always a next step laid out for users in their content journey.

Technical Insights

Each instance of the formatter can be configured to nominate which vocabularies should be used to determine the most related content. For example, when placing a list of ‘related programs or courses’, it might be appropriate to match the study area and level (e.g. undergraduate or postgraduate). 

Backfill Formatter in action: a client case study

University of Queensland’s Bachelor of Business Management – Explore other programs 

The University of Queensland (UQ) uses Backfill Formatter to suggest related content such as similar courses and associated news articles in their course information. 

UQ content admins can control these recommendations either fully or partially, with the CMS populating the remaining available space.

Helping small teams do more with less

In the quest for more extraordinary user experiences, our clients need straightforward solutions that overcome barriers to managing their typically large and numerous websites. 

Layout Builder, Entity Hierarchy and Backfill Formatter have all proven to be successful in supporting higher education institutions to keep delivering excellence online and in the lecture hall.

And whilst we enjoy spending time with our clients, we also make it possible for them to maintain their sites with less developer involvement!

This blog post is based on a showcase I gave at DrupalSouth 2021, you can see a recording of that here: https://youtu.be/z5gbLfHqPx4

Tagged

universities, higher education, recommended modules

Jamie Thomas with IBM talks about the OpenSFF and working to make open source software even more secure.
The post Jamie Thomas: What is the OpenSSF appeared first on Linux Foundation.

The post Jamie Thomas: What is the OpenSSF appeared first on Linux.com.

GSS-API is a standardized framework that is used by applications to, primarily, support Kerberos V5 authentication. GSS-API is standardized by IETF and supported by protocols like SSH, SMTP, IMAP and HTTP, and implemented by software projects such as OpenSSH, Exim, Dovecot and Apache httpd (via mod_auth_gssapi). The implementations of Kerberos V5 and GSS-API that are packaged for common GNU/Linux distributions, such as Debian, include MIT Kerberos, Heimdal and (less popular) GNU Shishi/GSS.

When an application or library is packaged for a GNU/Linux distribution, a choice is made which GSS-API library to link with. I believe this leads to two problematic consequences: 1) it is difficult for end-users to chose between Kerberos implementation, and 2) dependency bloat for non-Kerberos users. Let’s discuss these separately.

1. No system admin or end-user choice over the GSS-API/Kerberos implementation used

   There are differences in the bug/feature set of MIT Kerberos and that of Heimdal’s, and definitely that of GNU Shishi. This can lead to a situation where an application (say, Curl) is linked to MIT Kerberos, and someone discovers a Kerberos related problem that would have been working if Heimdal was used, or vice versa. Sometimes it is possible to locally rebuild a package using another set of dependencies. However doing so has a high maintenance cost to track security fixes in future releases. It is an unsatisfying solution for the distribution to flip flop between which library to link to, depending on which users complain the most. To resolve this, a package could be built in two variants: one for MIT Kerberos and one for Heimdal. Both can be shipped. This can help solve the problem, but the question of which variant to install by default leads to similar concerns, and will also eventually leads to dependency conflicts. Consider an application linked to libraries (possible in several steps) where one library only supports MIT Kerberos and one library only supports Heimdal.

   The fact remains that there will continue to be multiple Kerberos implementations. Distributions will continue to support them, and will be faced with the dilemma of which one to link to by default. Distributions and the people who package software will have little guidance on which implementation to chose from their upstream, since most upstream support both implementations. The result is that system administrators and end-users are not given a simple way to have flexibility about which implementation to use.

2. Dependency bloat for non-Kerberos use-cases.

   Compared to the number of users of GNU/Linux systems out there, the number of Kerberos users on GNU/Linux systems is smaller. Here distributions face another dilemma. Should they enable GSS-API for all applications, to satisfy the Kerberos community, or should they be conservative with adding dependencies to reduce attacker surface for the non-Kerberos users? This is a dilemma with no clear answer, and one approach has been to ship two versions of a package: one with Kerberos support and one without. Another option here is for upstream to support loadable modules, for example Dovecot implement this and Debian ship with a separate ‘dovecot-gssapi’ package that extend the core Dovecot seamlessly. Few except some larger projects appear to be willing to carry that maintenance cost upstream, so most only support build-time linking of the GSS-API library.

   There are a number of real-world situations to consider, but perhaps the easiest one to understand for most GNU/Linux users is OpenSSH. The SSH protocol supports Kerberos via GSS-API, and OpenSSH implement this feature, and most GNU/Linux distributions ship a SSH client and SSH server linked to a GSS-API library. Someone made the choice of linking it to a GSS-API library, for the arguable smaller set of people interested in it, and also the choice which library to link to. Rebuilding OpenSSH locally without Kerberos support comes with a high maintenance cost. Many people will not need or use the Kerberos features of the SSH client or SSH server, and having it enabled by default comes with a security cost. Having a vulnerability in OpenSSH is critical for many systems, and therefor its dependencies are a reasonable concern. Wouldn’t it be nice if OpenSSH was built in a way that didn’t force you to install MIT Kerberos or Heimdal? While still making it easy for Kerberos users to use it, of course.

Hopefully I have made the problem statement clear above, and that I managed to convince you that the state of affairs is in need of improving. I learned of the problems from my personal experience with maintaining GNU SASL in Debian, and for many years I ignored this problem.

Let me introduce Libgssglue!

Libgssglue is a library written by Kevin W. Coffman based on historical GSS-API code, the initial release was in 2004 (using the name libgssapi) and the last release was in 2012. Libgssglue provides a minimal GSS-API library and header file, so that any application can link to it instead of directly to MIT Kerberos or Heimdal (or GNU GSS). The administrator or end-user can select during run-time which GSS-API library to use, through a global /etc/gssapi_mech.conf file or even a local GSSAPI_MECH_CONF environment variable. Libgssglue is written in C, has no external dependencies, and is BSD-style licensed. It was developed for the CITI NFSv4 project but libgssglue ended up not being used.

I have added support to build GNU SASL with libgssglue — the changes required were only ./configure.ac-related since GSS-API is a standardized framework. I have written a fairly involved CI/CD check that builds GNU SASL with MIT Kerberos, Heimdal, libgssglue and GNU GSS, sets ups a local Kerberos KDC and verify successful GSS-API and GS2-KRB5 authentications. The ‘gsasl’ command line tool connects to a local example SMTP server, also based on GNU SASL (linked to all variants of GSS-API libraries), and to a system-installed Dovecot IMAP server that use the MIT Kerberos GSS-API library. This is on Debian but I expect it to be easily adaptable to other GNU/Linux distributions. The check triggered some (expected) Shishi/GSS-related missing features, and triggered one problem related to authorization identities that may be a bug in GNU SASL. However, testing shows that it is possible to link GNU SASL with libgssglue and have it be operational with any choice of GSS-API library that is shipped with Debian. See GitLab CI/CD code and its CI/CD output.

This experiment worked so well that I contacted Kevin to learn that he didn’t have any future plans for the project. I have adopted libgssglue and put up a Libgssglue GitLab project page, and pushed out a libgssglue 0.5 release fixing only some minor build-related issues. There are still some missing newly introduced GSS-API interfaces that could be added, but I haven’t been able to find any critical issues with it. Amazing that an untouched 10 year old project works so well!

My current next steps are:

• Release GNU SASL with support for Libgssglue and encourage its use in documentation.
• Make GNU SASL link to Libgssglue in Debian, to avoid a hard dependency on MIT Kerberos, but still allowing a default out-of-the-box Kerberos experience with GNU SASL.
• Maintain libgssglue upstream and implement self-checks, CI/CD testing, new GSS-API interfaces that have been defined, and generally fix bugs and improve the project. Help appreciated!
• Maintain the libgssglue package in Debian.
• Look into if there are applications in Debian that link to a GSS-API library that could instead be linked to libgssglue to allow flexibility for the system administrator and reduce dependency bloat.

What do you think? Happy Hacking!