Salut,
J'ai un peu de temps alors je vais développer une réponse plus longue, si ça peut te servir à avancer
La doc de schirrms.net est encore valable et je m'en suis servie il y a longtemps maintenant pour relier un apache et un tomcat fonctionnant sur deux SME. On peut tout faire avec le proxy reverse (HTTP, HTTPS, AJP, CGI, WSGI, etc....)
Tu peux tout te farcir à la main si tu veux apprendre à maitriser le proxy reverse sur SME mais il y a une contrib bien pratique de nos amis de firewall service :
sinon il y a la doc du wiki :
La bonne méthode reste toujours de créer les template-custom quand on doit tout faire à la main ou quand il n'y a pas de contrib pour le faire
Je ne connais que de nom Free-EOS qui me semble une distribution (un fork de SME) relativement ancienne, je vais donc plutôt te proposer des exemples tirés de mes notes d'administration concernant SME8.
Un exemple avec la contrib de FWS si tu peux l'installer sur Free-EOS:
un vtiger tourne sur SME2 mais c'est SME1 qui est ta passerelle;
alors en SSH sur ta SME1 (en root ou en sudo ):
yum --enablerepo=fws install smeserver-webapps-common
puis
db domains set crm.$(db configuration get DomainName) domain Content Primary Description 'VtigerCRM' Nameservers internet ProxyPassTarget https://sme2.domain.tld/vtigercrm/ TemplatePath WebAppVirtualHost AllowHosts local RequireSSL yes
Le SSL entre SME1 et SME2 n'est pas forcément nécessaire c'est à toi de voir, en revanche je privilégie le "fqdn" plutôt que l'ip dans ce cas pour éviter les problèmes de certificats.
De plus le paramètre "AllowHosts" est important pour définir les droits d'accès à SME2 mais peut être omis si l'accès est autoriser à tous!
signal-event domain-create crm.$(db configuration get DomainName)
ou si c'est une modification
signal-event domain-modify crm.$(db configuration get DomainName)
et enfin pour voir le résultat
db domains show crm.$(db configuration get DomainName)
signal-event webapps-update
En général, je relance apache et je teste le résultat.
/etc/init.d/httpd reload
Tout n'est pas forcément documenté pour cette contrib sur le site FWS, il va falloir regarder dans /etc/e-smith/templates/etc/httpd/conf/httpd.conf/WebAppVirtualHost les options possibles dans les fragments de template :
ls -l /etc/e-smith/templates/etc/httpd/conf/httpd.conf/WebAppVirtualHost
ou faire une recherche sur le wiki avec le terme "LemonLDAP" car FWS a developpé cette contrib pour leur solution de SSO basé sur LemonLDAP::NG.
Maintenant un deuxième exemple pour le fun puisque tu fais tourner du dotclear pour les blogs.
Le proxy reverse ça peut aussi servir sur le même serveur pour notamment sécuriser à moindre cout une installation multi-blogs de dotclear :
Sur ta future SME1, tu a installé dans /opt ou dans /home/httpd/html/blogs un dotclear en suivant la documentation officielle, tu as donc
- /home/httpd/html/blogs/blog1
- /home/httpd/html/blogs/blog2
- /home/httpd/html/blogs/dotclear
Tu vas créer trois domaines mais seulement les deux premiers seront accessibles de l'extérieur alors que dotclear.domain.tld ne sera accessible qu'en local
Il te faut avant tout avoir créer les template-custom pour permettre à apache d'accèder aux dossiers avec les bons droits sur les fichiers (voir la doc sur le wiki) sans les relier à des alias !
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf
cd /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf
nano 90e-smithAccess20dotclear_blog
tu y colles par exemple mais tu peux y mettre ce qui te convient mais pas d'alias :
# ------------------------------------------------
# Blogs avec Dotclear
# ------------------------------------------------
<Directory /home/httpd/html/blogs>
Options FollowSymLinks
AddType application/x-httpd-php .php .php3 .phtml
AddType application/x-httpd-php-source .phps
AllowOverride All
order deny,allow
deny from all
allow from all
php_flag magic_quotes_gpc off
php_flag magic_quotes_runtime off
php_admin_value eaccelerator.enable 1
php_admin_value open_basedir /home/httpd/html/blogs:/home/httpd/tmp
</Directory>
# ------------------------------------------------
# Fin des Blogs
# ------------------------------------------------
puis tu crées les domaines pour les blogs:
db domains set blog1.$(db configuration get DomainName) domain Content Primary Description 'Blog1' Nameservers internet DocumentRoot /home/httpd/html/blogs/blog1 TemplatePath WebAppVirtualHost
signal-event domain-create blog1.$(db configuration get DomainName)
signal-event webapps-update
db domains show blog1.$(db configuration get DomainName)
Tu le fais autant de fois que nécessaire puis tu crées le domaine pour l'administration des blogs :
db domains set dotclear.$(db configuration get DomainName) domain Content Primary Description 'Admin Blogs' Nameservers internet DocumentRoot /home/httpd/html/blogs/dotclear/admin TemplatePath WebAppVirtualHost AllowHosts local RequireSSL yes
signal-event domain-create dotclear.$(db configuration get DomainName)
signal-event webapps-update
db domains show dotclear.$(db configuration get DomainName)
Pour finir d'optimiser ton installation de dotclear, il te faut créer des liens symboliques pour tous tes blogs :
ln -s /home/httpd/html/blogs/blog1/themes /home/httpd/html/blogs/dotclear/themes
ln -s /home/httpd/html/blogs/blog1/public /home/httpd/html/blogs/dotclear/public
maintenant les blogs vont tous pouvoir utiliser les mêmes thèmes, les mêmes plug-ins...etc et tu vas gagner en espace disque
Pour aujourd'hui je crois que ça va suffir, mais si tu as besoin d'exemple de template-custom fait main alors fais nous signe.
Je n'ai pas traité des problèmes de sécurité liés au proxy reverse parce que ne sachant pas ton niveau de connaissance je suppose que tu sais sécuriser, superviser, sauvegarder et auditer un serveur linux.
Enfin, une opinion en toute humilité :
sur le forum d'ixus (
http://forums.ixus.net/viewtopic.php?f=19&t=32603) il a été présenté différentes manières de placer une SME derriere une box. Pour avoir essayer toutes les configurations, il me semble préférable de ne pas mettre une SME en DMZ, non pas qu'elle ne puisse pas tenir son rang mais vu le cycle de développement (ce n'est pas une critique contre les dev) fatalement la SME a tendance à présenter des failles.
Quelques exemples :
- Les kernel stables en sont à la version 3.9.x (https://www.kernel.org/), les versions 3.0.x sont parfaitement fonctionnels sur el5(il faut patcher un peu SME8, voir le site ELrepo)
- Iptables en est à la version 1.4.18 (http://netfilter.org/), cette version est tout à fait fonctionnelle sur SME8 après compilation et correction du script "masq" qui présente quelques erreurs de conception
- xtables-addons 1.47.1 nécessite une version récente du kernel et d'iptables pour permettre d'exploiter tarpit ou bien même geoip
Mes SME8 en production ne sont plus que des lointaines parentes de la SME8 livré sur l'ISO. Même si SME9 est sur la bonne voie, la distribution aura toujours du retard sur la correction de quelques failles de sécurité ou l'implémentation de nouvelles fonctionnalités. On peut tout faire avec SME mais il faut rester prudent et je pense qu'il vaut mieux, quand on peut, disposer d'une passerelle SME "private gateway"sur une IP et d'un serveur d'hébergement web sur une autre ip. Donc si tu peux, gardes tes deux serveurs
- places en un, en 192.168.1.2 pour servir de private gateway vers ton lan
- places l'autre, en 192.168.1.3 pour servir de server only vers lequel tu rediriges les ports de la box pour les services (80, 443, 25, SSH mais pas 22, etc...)
- un fail2ban bien paramétré avec les regex qui vont bien pour SSH, HTTP et SMTP
- voire un portsentry 1.2beta pour ralentir les scan de port
- xt_geoip pour limiter les accès à tes serveurs en fonction de l'origine de l'IP
- tarpit pour ralentir les pénibles
- enfin du cache (Memcached) et un optimiseur php (eAccelerator)
Cette manière de faire est plus contraignante mais assure selon moi une meilleure sécurité, la possibilité de mieux répartir la charge et surtout d'éteindre la passerelle pendant les vacances
A+
Xavier