Issue

Email from a Drupal website on OIT Web Hosting is being delivered to non-Georgia Tech email addresses, but is failing on Georgia Tech email addresses (@gatech.edu).

Solution

To fix this issue, ensure that the From: email address in Drupal (set in Configuration -> Site Information) is a valid Georgia Tech email address.

More details, per OIT Web Hosting:

Since this problem has come up more frequently, I’ll clarify what the issue is:

outbound.gatech.edu requires that if you are sending to *@*.gatech.edu address that the OIT MX servers handle (which is most of them), the “From:” address has to be a valid Georgia Tech address. Along with this, if the “From:” address isn’t valid, there is no way for outbound.gatech.edu to send a bounce message back.

This is a requirement of the OIT MX servers and isn’t related to anything that Web Hosting restricts.  In fact, on the Web Hosting servers, the message shows as sent, but that just means it was sent on to outbound.gatech.edu.

Issue

You've upgraded your Drupal 8 site to 8.8+ and now get the following warning in your site's Status Report.

Deprecated configuration
You are using deprecated configuration for the temporary files path. Your temporary directory configuration
matches the OS default and can be safely removed.

Cause

Drupal 8.8 changed some of the configuration handling for the temporary file path, moving storage of that path into a config system key.  However, that key is not directly editable, and under certain odd circumstances can get populated with the default system temporary directory path.

Solution

Warning: the following is minimally tested, and while it seems to work, be cautious and consider testing on a copy of your site first.  At a minimum, back up your database before trying this to be safe.

Putting the following into a module file temporarily and pulling up any page in the site should clear the value of the config key:

\Drupal::service('config.factory') -> getEditable('system.file') -> clear('path.temporary') -> save();

If the warning message then disappears from your Status Report, you can remove the above line from wherever you put it.

Issue

Below is a quick summary of what you need to do if you are changing your Drupal site's host name / domain name without moving it to a new web hosting location.

If you are moving the site to another location, then you'll also need to see the Site Migration section for additional guides.

Solution

1. First, go ahead and request that your new host name be created in DNS and pointed to your existing web server.  You'll need to know the host name and/or IP address of your existing server to provide to your DNS administrator.  If you don't know either, then provide the current host name for your website, and your DNS administrator should be able to determine the web server hostname and IP address from it.

2. Configure your web server to recognize the new host name.  If you are using an automated web hosting solution like OIT's Web Hosting, then go into your control panel and add the new host name as a domain alias for your hosting account.

3. Check your site for links hard coded to your old host name:
   • The quickest way of doing this (though it does require some advanced knowledge) is to dump your database out to an SQL file and do a search through that file for instances of your old host name and then identify the pages that need to be updated.  
   • Alternatively, you could go through every page, opening each one up for editing, and check the page source for every inline link and every inline image.  

   If you don't fix these links, then users will be silently switched over to the old hostname when they follow those hard coded links, and when you eventually delete the old hostname from DNS, those links will simply break.

4. If you want to force everyone to view your site through the new host name (which is important for Search Engine Optimization), you can add something like the following to your .htaccess file, where oldsitename.gatech.edu and newsitename.gatech.edu are replaced with the appropriate values:

     RewriteCond %{HTTP_HOST} ^oldsitename.gatech.edu [NC]
     RewriteRule ^ http%{ENV:protossl}://newsitename.gatech.edu%{REQUEST_URI} [L,R=301]
   

As announced by the Office of Information Technology on 2/4/2021:

We would like to inform you of changes to Identity & Access Management’s plan to upgrade Single Sign-On (SSO) services CAS 6. The CAS upgrade includes an upgrade from CAS 3 to CAS 6, merges CAS and Shibboleth/SAML2 SSO services, and improves the SSO service’s availability, security, and sustainability. Unlike the original plan, which involved a single upgrade window, this upgrade will occur in phases over the next several weeks to allow application owners to appropriately test, prepare, and upgrade in phases.

In order to streamline this process and avoid downtime, service owners are asked to test their applications against the new version throughout this process to make sure your applications remain compatible.

Remainder of post copied at the end of this page

If you are running a Drupal site that uses GT Account Username authentication (also known as CAS authentication), then you should know the following:

• A CAS 6 server has been set up and is available at sso.gatech.edu .  You can start testing against this server if you wish.

• If your Drupal site is running Drupal 8 or Drupal 9, you do not have to do anything (but see the warning below).

• If your Drupal site is running Drupal 7 or earlier, you should make sure you are on the latest version of phpCAS (currently 1.3.8).

• Warning: If you do not update your configuration to point to sso.gatech.edu, your site editors will have to log in a second time to access your site during Phase 3 (see below for exact dates), and will receive a warning that your site is still using the legacy authentication server.  If you don't mind this happening for a period of about one month, the warnings will go away at the start of Phase 4, when the old authentication server address will be automatically redirected to sso.gatech.edu

• To update your site to point to sso.gatech.edu:

  • For Drupal 8 or 9:

    1. Go to the CAS configuration page on the black administration toolbar under Configuration -> People -> CAS ; alternatively, you can access the configuration page by adding "/admin/config/people/cas" to the end of your site's front page URL.

    2. Under CAS Protocol version, select 3.0 or higher

    3. Under Hostname, enter "sso.gatech.edu" (without the quotes).

    4. If you want to check the rest of your settings, see our Drupal 8/9 CAS Configuration Page.

    5. Don't forget to scroll down and Save configuration.

  • For Drupal 7:

    1. Go to the CAS configuration page on the black administration toolbar under Configuration -> People -> CAS settings ; alternatively, you can access the configuration page by adding "/admin/config/people/cas" to the end of your site's front page URL.

    2. Under Version, select 3.0 or higher

    3. Under Hostname, enter "sso.gatech.edu" (without the quotes).

    4. If you want to check the rest of your settings, see our Drupal 7 CAS Configuration Page.

    5. Don't forget to scroll down and Save configuration.

Remainder of original OIT post about CAS upgrades:

The schedule and impact for each phase is as follows:

Phase 1: Wednesday, February 10 – No Impact

Sso.gatech.edu will be launched as a new production instance of CAS 6. No action is required. Application owners should begin migrating or plan migration to the new system after this date. Testing is also encouraged to ensure that the migration will be successful.

Phase 2: Wednesday, February 17 – Possible Impact to Shibboleth Applications

Shibboleth/SAML2 applications (those that use idp.gatech.edu for logins) will transition to the new instance of CAS 6. Login sessions will be shared between CAS 6 and CAS even if application systems have not been upgraded. At this point, all application owners should be in the process of migrating to the new system. Testing is also encouraged to ensure that the migration will be successful.

Phase 3: Thursday, March 11– Impact to Any Applications that have not Upgraded

CAS 6 login sessions will no longer be shared with CAS. Users of applications that have not been migrated to CAS 6 will see warnings that they are using a deprecated login system and that the application should upgrade to sso.gatech.edu by Wednesday, April 21 or risk login problems. Application owners should continue migrating to the new system. Testing is also encouraged to ensure that the migration will be successful.

Phase 4: Wednesday, April 21 – Impact to Any Applications that have not Upgraded

At this phase, most applications should be upgraded to CAS 6. All remaining applications will automatically be upgraded. Login.gatech.edu will begin automatically redirecting to sso.gatech.edu.

Please note that CAS, SAML1, SAML2, Shibboleth, and ADFS will be affected by this upgrade. During the final phase (Wednesday, April 21), visits to login.gatech.edu will be automatically redirected to the new system at sso.gatech.edu.

Throughout the duration of this upgrade, application owners will receive regular communications including weekly updates surrounding each phase and ongoing reports to show the status of application upgrades. You will also receive a calendar invite from the IAM team shortly after receiving this message inviting you to weekly work sessions/open office hours for assistance with upgrading systems. Finally, "open mic" Teams sessions are scheduled during the change windows for instant collaboration between application owners, users, and the IAM team.

For additional information about this upgrade, using your VPN, please visit http://b.gatech.edu/CAS6-upgrade or contact Nadeem Rizvi at nrizvi@gatech.edu.