Bonsoir,

Installer plusieurs versions de php n'est pas forcement compliqué,
par exemple sur debian avec le repo deb.sury.org.
Il suffit ensuite de lancer plusieurs php-fpm.
Chaque appli peut avoir un utilisateur dédié, utilisable pour les directives apache mpm-itk et le process php-fpm.

J'aime bien garder haproxy pour la terminaison ssl devant tout ça.



Le mar. 5 mars 2024, 21:25, N R <randria.nicolas@gmail.com> a écrit :
Bonsoir la liste,

Merci pour vos réponses.

Pardon pour le manque de clarté de mon message, je ne cherche pas à faire du multi-client, mais merci Maxime Pauwels pour la recommandation d'ISPconfig.

Le besoin c'est héberger un serveur icinga, un serveur wazuh et un site statique sur la même machine.
Les données de supervision seront collectées via un vpn Wireguard.

Initialement j'étais parti pour faire un truc simple avec un nginx (possiblement tester le fork libre) ou un apache proprement configuré pour faire du multi-domaine en frontal comme il a été suggéré ici.
J'ai eu un doute à cause d'une mauvaise expérience en essayant d'installer Icinga sur le même serveur qu'un Nextcloud existant qui n'utilisaient pas les mêmes versions de PHP, d'où mes questions sur les containers.

Je pense partir sur un truc un peu hybride, mettre un front-end nginx directement installé sur la machine et des conteneurs lxc, j'ai déjà un peu bidouillé, ce sera l'occasion de pratiquer plus.

Sur la digression WAF, j'ai récemment découvert NAXSI qui s'intègre à nginx, ce sera l'occasion de tester.

Je garde les solutions avec du traefik et du docker pour d'autres cas, là j'ai peur que ce soit un peu trop pour le temps que j'ai envie de consacrer à la maintenance de la supervision.

Encore merci pour toutes les réponses,
Bien à vous,

Kholah

Le lun. 4 mars 2024 à 18:16, Mathieu Arnold <m.arnold@ovea.com> a écrit :
On Mon, Mar 04, 2024 at 01:22:37PM +0000, Louis G. via FRsAG wrote:
> Hello,
>
> > Comme apache sait gérer les fichiers plats et le php, c'est plus simple à maintenir que des piles nginx+php-fpm, et comme c'est derrière un traefik, y'a moins de chance de le casser à cause d'une faille.
>
> Je suis curieux, pour moi Traefik est un simple reverse-proxy et ne fait (par défaut, peut-être que y'a des plugins) pas WAF. Donc j'ai du mal à comprendre quelle sécurité apporte Traefik vs n'importe quel autre reverse-proxy.
>
> Je suis à coté de la plaque ou Traefik est effectivement plus "intelligent" que ça ? Ou tu sous-entendais que Apache en frontal c'est bof ?

C'est pas un WAF, mais il va terminer le SSL et faire reverse proxy,
donc en cas de trou de sécu dans le serveur web qui est derrière, ça
complique l'attaque vu que traefik ne va pas laisser passer une requête
sensée exploiter un bug du serveur qui est derrière telle quelle, vu
qu'il fait proxy et réécrit des bouts, il y a de bonnes chances que la
requête malicieuse ne le soit plus.

--
Mathieu Arnold
_______________________________________________
Liste de diffusion du %(real_name)s
http://www.frsag.org/
_______________________________________________
Liste de diffusion du %(real_name)s
http://www.frsag.org/