Overhaul deployment considerations documentation

[enbrnz]

WHAT Needs to be Documented?

The page seems to have a few dubious statements that should be confirmed and/or revised. I just did a quick read and noticed the following issues:

GPFS or Ceph via phprados

Do we actually support that? I think a more common approach nowadays would be to use S3 compatible storage.
Within in the same section is missing that the web application servers need to all have access to a shared temp/upload storage.

CentOS is the community-supported free-of-cost Red Hat Enterprise Linux clone.

This is no longer true. Alma or Rocky Linux would be correct now.

Mod_php is recommended instead of PHP_FPM, because in scale-out deployments separate PHP pools are not necessary.

This sentence makes no sense? @voroyam
The technical reasons for mod_php usage are: QA testing only with mod_php and Shibboleth used to not be compatible with FastCGI (PHP-FPM) (at least not without recompiling). Please correct me if I am wrong @DeepDiver1975 @butonic

Redis is required for transactional file locking [...], and graphical inspection tools available.

What is meant by that? What is its use case?

If you need to scale out Shibboleth you must use Memcached, as Shibboleth does not provide an interface to Redis. Memcached can also be used to scale-out shibd session storage

This seems incorrect to me: Shibboleth Session Storage

[...]

• Each application can (and usually does) maintain distinct sessions with the browser.

All these sessions are pretty much independent and distinct: any session can exist with or without any other session, and the expiration of any one session does not imply the expiration of any other session.

So once you are logged in to ownCloud using Shibboleth SSO, apache should be able to store the session in Redis. When a new request with a valid session comes to web application server X instead of Y, the valid session should be found in the Redis session storage.

I think once you are scaling out a Shibboleth enabled Web application server you need to make sure that all Web Application Server's Shibboleth daemons have a common session storage as well. At least that is my conclusion after reading the following additional articles:

https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334626/StorageService
https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334650/SessionCache

Not sure who else knows how this needs to be implemented and can review my conclusion? @DeepDiver1975

WHERE Does This Need To Be Documented (Link)?

https://doc.owncloud.com/server/10.11/admin_manual/installation/deployment_considerations.html

WHY Should This Change Be Made?

The current docs have room for improvement. It would be nice if a few more knowledgeable people could double check what's written here: @cdamken @IljaN @pako81 @ChrisEdS @dj4oC

(Optional) What Type Of Content Change Is This?

• New Content Addition
• Old Content Deprecation
• Existing Content Simplification
• Bug Fix to Existing Content

(Optional) Which Manual Does This Relate To?

• Admin Manual
• Developer Manual
• User Manual
• Android
• iOS
• Branded Clients
• Desktop Client
• Other

[DeepDiver1975]

This sentence makes no sense? @voroyam
The technical reasons for mod_php usage are: QA testing only with mod_php and Shibboleth used to not be compatible with FastCGI (PHP-FPM) (at least not without recompiling). Please correct me if I am wrong @DeepDiver1975 @butonic

mod_php is basically the only setup which is used in dev and QA. Back in the days (about 10 years or so) fpm was not as stable as it is today - or let's say mod_php was easier to setup for the broad mass of users.
while fpm is a valid php setup (meanwhile) we still do not honor it in dev and qa.
from an enterprise support point of view we only support mod_php afaik - but anybody is free to correct me

[voroyam]

Thanks for raising this issue.

It's important that we have clear documentation what we recommend and why.