Succesfully running (annoying bug, but running) FarmOS on Kubernetes (AKS - AZURE) (SOLVED!)

Hosting farmOS
1

Hi folks, I have it up and running on Kubernetes (AKS - AZURE) and I would be more than happy to write an article to help everyone else to do the same.

There is one small and annoying issue to take care of first, during the installation at the end of each stage it would redirect back to the http version of the address instead of keeping the https, upon adding the “s” and reloading the page I was able to just continue the installation.

I have found so far that whenever a user is created or logs out it also redirects to http instead of https, adding the “s” and reloading takes care of it, so far I haven’t found any other operations that would cause the redirection, but I assume that they are there, just waiting to bite me.

It currently sits behind an Application Gateway with WAF on it, which is rock solid (there are 200 applications running on the AKS Cluster on https at the moment), so no problems in the K8s side of things.
Long story short, after trying for 2 days and not being able to access it, then not going past the first installation steps and going through tons of different posts on the internet, this is what I was able to find to configure it, and get it to the stage where it is now:

              mkdir -p /opt/drupal/web/sites/default/files
              mkdir -p /opt/drupal/web/sites/default/private/files
              chown -R www-data:www-data /opt/drupal/web/sites/default/private/
              chown -R www-data:www-data /opt/drupal/web/sites/default/files
              chmod 770 /opt/drupal/web/sites/default/private/files
              chmod 770 /opt/drupal/web/sites/default/files
              chown -Rv apache:apache www-data:www-data /opt/drupal/web/sites/
              cp /opt/drupal/web/core/assets/scaffold/files/default.settings.php /opt/drupal/web/sites/default/default.settings.php
              chown www-data:www-data /opt/drupal/web/sites/default/default.settings.php
              cp /opt/drupal/web/sites/default/default.settings.php /opt/drupal/web/sites/default/settings.php
              chown www-data:www-data /opt/drupal/web/sites/default/settings.php
              echo "\$settings['reverse_proxy'] = TRUE;" >> /opt/drupal/web/sites/default/settings.php
              echo "\$settings['reverse_proxy_trusted_headers'] = \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL;" >> /opt/drupal/web/sites/default/settings.php
              echo "\$settings['file_private_path'] = '/opt/drupal/web/sites/default/private/files';" >> /opt/drupal/web/sites/default/settings.php
              echo "\$config['system.logging']['error_level'] = 'verbose';" >> /opt/drupal/web/sites/default/settings.php
              echo "\$settings['clean_url'] = 1;" >> /opt/drupal/web/sites/default/settings.php
              echo "\$base_url = 'https://mysite-my.example.com';" >> /opt/drupal/web/sites/default/settings.php
              # Adding the PHP script to handle X-Forwarded-Proto header
              echo "if (isset(\$_SERVER['HTTP_X_FORWARDED_PROTO']) && \$_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') { \$_SERVER['HTTPS'] = 'on'; }" >> /opt/drupal/web/sites/default/settings.php
              awk '/<IfModule mod_rewrite.c>/ { print; print "# Ensure HTTPS for all requests\nRewriteEngine On\nRewriteCond %{HTTP:X-Forwarded-Proto} !https\nRewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]"; next }1' /opt/drupal/web/.htaccess > /opt/drupal/web/.htaccess.new && mv /opt/drupal/web/.htaccess.new /opt/drupal/web/.htaccess

So basically I covered settings.php and .htaccess, if anyone has a hint on why the redirections to http are happening, I would appreciate the help.
FarmOS image 2.1.1

2 Likes
2

Welcome to the farmOS forum @brdarkmoon! :smile:

I have dealt with similar behavior in the past when setting up farmOS behind reverse proxies, so I would bet that it’s the same here.

If I remember correctly, the solution is to add $conf['reverse_proxy_addresses'] = ['1.2.3.4', ...]; to your settings.php with the IP addresses of all reverse proxies that you are using AND to make sure that your proxy is setting the HTTP_X_FORWARDED_PROTO header to https before forwarding the request to your Drupal container.

You do not need to set $_SERVER['HTTPS'] = 'on' - Drupal takes care of everything else for you automatically.

For more information, see:

https://www.drupal.org/node/425990

Hope that helps!

1 Like
3

Thank you very much, it’s great to be welcomed here.
And thank you very much for the answer @mstenta , but the thing is, I can’t use the
$conf['reverse_proxy_addresses'] = ['1.2.3.4', ...]; approach because the reverse proxy is an Azure Application Gateway and I don’t have it using a private IP address, only the public one.
From a network and logical perspective, it is something like this:

User ↔ AGW ↔ Ingress ↔ SVC ↔ FarmOS_POD

1 Like
4

If you both trust your proxy (not to forward the wrong headers/values) and are confident that the farmOS pod is only accessible by the proxy (i.e. in a private network) then you could do this;

$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = [$_SERVER['REMOTE_ADDR']];
$conf['reverse_proxy_trusted_headers'] = \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL;

Obviously, YMMV & at your own risk :laughing:

1 Like
5

Thank you @Symbioquine .
FarmOS sits inside a cluster behind a WAF and the Reverse proxy is integrated in it, and there is active monitoring.
I am already adding 2 of your suggested lines, but you say $conf whereas I am using $settings, which one is the correct one?

          echo "\$settings['reverse_proxy'] = TRUE;" >> /opt/drupal/web/sites/default/settings.php
          echo "\$settings['reverse_proxy_trusted_headers'] = \Symfony\Component\HttpFoundation\Request::HEADER_X_FORWARDED_ALL;" >> /opt/drupal/web/sites/default/settings.php

So, depending on what is the correct one, what should I add:?

$conf[‘reverse_proxy_addresses’] = [$_SERVER[‘REMOTE_ADDR’]];

or

$settings[‘reverse_proxy_addresses’] = [$_SERVER[‘REMOTE_ADDR’]];

1 Like
6

So, I gave up tweaking it at the application level and went directly to the Application Gateway and wrote a redirect rule, anyone deploying with the same setup as me (AKS, AGW and WAF) will be able to solve this particular problem using the same solution, problem solved!!!
Thank you all for your willingness to help me up here.
Btw, I would be more than happy to write an article on how to deploy this on an AKS cluster with WAF and AGW in front of it, just point me to where I should write it and I will do it.
P.S:
While digging through the UI, I found this though:

image
image1340×533 32.2 KB

Could that be interfering with the redirection? If the answer is yes, then how to we put it to https at deployment time? could be useful for a different setup

1 Like
7

Probably $settings. I was adapting from a slightly different context so I might have mixed that part up.

1 Like