Implications of disabling the portal RewriteEngine

Get Help
1

On our system there is a problem with accessing our ondemand portal off campus using securelink.
While troubleshooting our admin traced it down to the RewriteEngine in /opt/rh/httpd24/root/etc/httpd/conf.d/ood-portal.conf — turning the RewriteEngine off solves the issue in securelink.

So two things…

1.) Is the RewriteEngine needed by the OnDemand portal?
2.) If not how do we turn it off properly? Because if we turn it off in the apache file it will get overwritten next time /opt/ood/ood-portal-generator/sbin/update_ood_portal is run.

2

I believe RewriteEngine is enabled only to enforce two rewrite rules:

Redirect all http traffic to https, if SSL is enabled:

This is the other RewriteRule in use but I’m not sure yet why. @tdockendorf do you know what the ramfications are of removing these rewrite rules?

Do you know why RewriteEngine is causing the problem?

Also, we do have this problem with the apache file getting overwritten the next time /opt/ood/ood-portal-generator/sbin/update_ood_portal is run. That script does make a backup before overwriting so you could reapply the changes after the fact, but that is not ideal. Another option is to modify the template that is used by the script at /opt/ood/ood-portal-generator/templates/ood-portal.conf.erb. I think if you modify that file, when you do an rpm update the modified template will be preserved and the new template will be with a “.new” after it. You would still be responsible for diff-ing the two and merging any changes manually.

3

The readwrite rule for port 80 VirtualHost is to force SSL if someone goes to non-SSL URL. This is a convenience redirect and can be removed if you’re not concerned with people forgetting to use https:// when they request ondemand.

The readwrite rule for port 443 on first glance looks like it redirects anything not using port 443 to port 443 which seems kind of unnecessary as it’s already inside port 443 VirtualHost.

Changes to ood-portal.conf.erb will NOT persist through RPM updates, it’s not flagged as a config file. If there is no way to support rewrites with securelink then we’d need to modify the template to support turning off rewrite engine via new option.

4

I think I remember what the port 443 redirect does. I think it’s intended to redirect any hostname on port 443 to the proper ondemand hostname. So like our server name is web02.hpc.osc.edu but OnDemand is intended to use ondemand.osc.edu. If someone goes to https://web02.hpc.osc.edu it will redirect to https://ondemand.osc.edu. This was needed to ensure communications with our authentication provider would work regardless of how OnDemand was accessed.

If you can ensure people are always using the proper URL then all the rewrite rules can be turned off.

1 Like
5

@lsmatott This may give you an idea of what changes would be needed to support this in the portal generator: https://github.com/OSC/ondemand/pull/40

6

@lsmatott Trey’s PR was pulled in and we are making one final build of 1.6 so when 1.6 is available you can set in the /etc/ood/config/ood-portal.conf use_rewrites: false and then execute /opt/ood/ood-portal-generator/sbin/update_ood_portal and the RewriteEngine rules will be omitted.

1 Like
7

We are ready to upgrade to version 1.6.7 and test the new ability to disable the RewriteEngine. One question ---- what, if any, OnDemand customizations (https://osc.github.io/ood-documentation/master/customization.html) will be affected by upgrading the version? We’ve added the following to the base installation: added institutional branding, added message of the day, enabled interactive apps, and customized the help URLs. Will we need to re-apply these customizations after we upgrade?

— Shawn

image001.jpg

8

If you are upgrading from 1.5 here is the main feature list: https://osc.github.io/ood-documentation/master/release-notes/v1.6-release-notes.html

There should be no breaking changes in regards to customization you already have. Since all of those customizations are stored in /etc/ood/config, the upgrade shouldn’t overwrite anything.

Note that the upgrade may result in generating a new /opt/rh/httpd24/root/etc/httpd/conf.d/ood-portal.conf. If you have manual edits to that file, a backup of that file should be copied to a dot back up file so you may need to manually merge back those changes into the new ood-portal.conf.

Of course, its recommended to have a test OnDemand server alongside a production OnDemand server so when you upgrade anything on that node including OnDemand you can confirm things are working as expected before doing the same in production.