import d'articles depuis pluxml

content/Discussions/marre-filtrage-securite-hebergeurs.md

@@ -0,0 +1,87 @@
+Title: Marre du filtrage "sécurité" des hébergeurs !
+subtitle: ; On rale
+Date: 2012-09-05 18:57
+Modified: 2012-09-05 18:57
+Tags: online, hébergement, sécurité, blocage
+keywords: online, hébergement, sécurité, blocage
+Slug: marre-filtrage-securite-hebergeurs
+Authors: Victor
+Status: published
+
+[TOC]
+
+## Votre hébergeur roxx !
+
+<p>Auneffet, ses serveurs HP et DELL vous donne accès à une carte ILO ou DRAC, qui permet de faire plein de choses sympas pour gérer votre serveur à un niveau supérieur.&nbsp;</p>
+
+<p>Entre autre, grâce à ces cartes, vous pouvez décider de booter votre serveur sur une iso de votre cru, qui est bien sûr votre distribution Linux préférée trop bien que vous pouvez plus vous en passer.</p>
+
+<p>(Ou alors, vous voulez juste installer un système en gérant correctement le partitionnement, ce qui est pas encore gagné via les interfaces web...).</p>
+
+<p>&nbsp;</p>
+
+<p>Sauf que bon, charger une image iso de 600Mo depuis chez vous, avec votre ADSL de merde by "******", ça rend tout de suite le truc moins sexy.</p>
+
+<p>C'est alors que tout frétillant vous vous dites "Mais oui" !</p>
+
+<p>Car oui ! vous avez un autre serveur dédié chez le même hébergeur (car décidément vous le kiffez à mort).</p>
+
+<p>Quoi de plus simple alors que d'installer une petite machine virtuelle sur le deuxième serveur, avec une interface graphique pour lancer la magnifique applet (<a href="http://fr.wikipedia.org/wiki/Appliquette">appliquette</a>) java permettant de faire votre bonheur ?</p>
+
+## Et ouais. Sauf que non
+
+<p>[MODE GROGNE : ON]</p>
+
+<p>Car, pour des raisons plus ou moins fallacieuses, vous allez vite déchanter.</p>
+
+<p>Votre hébergeur, dans un souci constant de pourvoyer à votre sécurité (Ca fait partie du contrat ??) applique un filtrage sur ce qui se passe dans son réseau.</p>
+
+<p>Manque de bol, il considère ses propres adresses IP comme pas de confiance, et donc bloque tout accès à sa propre console depuis une machine de son propre réseau. (On croit rêver...)</p>
+
+<p>Comment font les techniciens pour intervenir ? Mystère... Sans doute un VPN/proxy installé chez un concurrent est-il le seul moyen pour les pauvres hères de travailler dans des conditions décentes.</p>
+
+<p>Quoiqu'il en soit, après avoir installé votre distribution GNU/Linux avec une interface graphique GNU/Linux, avoir fait la configuration de NAT qui va bien (car votre hébergeur <strike>est toujours un gros extrémiste</strike> sécurise son réseau, <a href="#Et en plus...">voir plus bas</a>) vous chargez votre navigateur libre préféré, et vous vous mangez un méchant "403, Forbidden". Autrement nommé "Mais c'est pas vrai, y'a une erreur ! WTF ?"</p>
+
+<p>Sauf que, forum à l'appui, d'erreur il n'y a point.</p>
+
+<p>Pour éviter tout système de rebond (Entendez un méchant qui a piraté un serveur et qui voudrait accéder à la console pour en acheter un autre), on bloque, sans possibilité de rémission. Sans se poser de questions. Et tant qu'à faire, sans même un message un peu verbeux (403 Forbidden Apache powaa!)</p>
+
+<p><strong>Résultat des courses : </strong>Vous vous résignez finalement à charger votre iso via votre machine locale, avec votre connexion ADSL à l'upload plus que douteux. Si en plus vous êtes en entreprise et que tout le reste de la boîte utilise la même connexion pour powner du FTP ou télécharger des contenus sous licence Creative Commons, préparez vous à avoir des remontées violentes. Mais bon vous bossez, c'pas d'votre faute hein.</p>
+
+<p>&nbsp;</p>
+
+<p><strong>Résultat des courses, 2eme vue :&nbsp;</strong>Vous avez perdu 1h à installer votre machine virtuelle, pour rien. Vous perdez ensuite 5h de votre journée à regarder avancer une jauge à la con. Bah oui, parce que comme c'est sécurisé, il y a un timeout, donc si jamais vous êtes pas là à cliquer régulièrement sur votre applet java pour lui dire que sisi, ça bosse toujours, vous êtes bons pour recommencer.</p>
+
+<p>Accessoirement, avec un upload moyen de 70Kb/s, vous allez encore moins vite qu'un lecteur CD 1x. Croyez moi, s'pas gagné.</p>
+
+## <a name="Et en plus...">Et en plus...</a>
+
+<p>Et en plus, comme votre hébergeur <strike>est toujours un gros extremiste</strike> sécurise son réseau, pendant que vous configuriez votre petite machine virtuelle (avant de vous rendre compte que ça servait à rien, j'entends) vous avez commencé par la lancer avec une IP privée, comme ça à l'arrache.</p>
+
+<p>Sauf que, ni une, ni deux, elle a envoyé quelques paquets innocent avec son adresse privée et sa MAC bidon sur le réseau de votre hébergeur (bah oui, pas eu le temps de configurer un NAT, ou même d'y penser). Celui-ci, malin, va bloquer ces paquets rapidement.</p>
+
+<p>Mais aussi, parce que ça ne mange pas de pain, il va également bloquer tout accès à votre serveur ! Plus de SSH, plus d'interface web, même plus de console en ligne ! (Sans parler d'ILO ou de DRAC)</p>
+
+<p>Pendant un temps plus ou moins variable, vous ne pouvez plus rien faire. Sans même savoir pourquoi d'ailleurs, puisque vous avez juste droit à un gros message rouge vous disant que "c'est con hein, mais c'est bloqué. C'est votre faute z'aviez qu'à pas &lt;Insert blank here&gt;".</p>
+
+<p>Pour peu que à peine le réseau revenu vous refassiez la même erreur 2, 3, 4 fois avant de comprendre ?</p>
+
+<p>Pour peu que vous ayiez lancé un ping sur votre VM pour tester la connexion, et qu'au fur et à mesure que le réseau soit débloqué, la VM continue son ping et vous rebloque de nouveau...</p>
+
+<p>Vous avez perdu encore une petite heure, au bas mot. (Soyons large, on est des pros ici, on comprends vite d'où ça peut venir ces petites erreurs là.)</p>
+
+<p>&nbsp;</p>
+
+## Mais au final
+
+<p>Au final, vous avez déjà perdu 7h, vous êtes plus à ça près, s'pas ?</p>
+
+<p>Et puis, ça vous laisse plein de temps pour chercher avec votre connexion surchargée le nom d'un autre hébergeur chez qui migrer au plus vite... Pour vous rendre compte qu'en fait, ils sont tous hors de prix tout en étant pire dans leur gestion réseau.</p>
+
+<p>&nbsp;</p>
+
+<p><strong>Conclusion :&nbsp;</strong>L'auto-hébergement, c'est le bien !</p>
+
+<p>[MODE GROGNE : OFF]</p>
+
+<p><em>Nota : bien sûr, personne ne doit se sentir insulté ou calomnié par ce texte, résultat de mon cerveau brouillon et sans prétention devant tant de capacités techniques employées pour faire le bien.</em></p>

content/Réseaux/dns-dynamique-ovh-avec-wrt54gl.md

@@ -0,0 +1,90 @@
+Title: Utiliser un DNS dynamique chez OVH avec un WRT54GL sur tomato
+Date: 2012-09-11 21:16
+Modified: 2012-09-11 21:16
+Tags: DynDNS OVH, DNS dynamique, tomato, WRT54GL
+keywords: DynDNS OVH, DNS dynamique, tomato, WRT54GL
+Slug: dns-dynamique-ovh-avec-wrt54gl
+Authors: Victor
+Status: published
+
+[TOC]
+
+## Oui, le titre est long, et alors ?
+
+<p>Si on faisait toujours des titres courts, ça serait pas référencés sur Google ! (#oupas)</p>
+
+<p>Bon, cet article est sérieux, attaquons.</p>
+
+<p>&nbsp;</p>
+
+<p>Dernièrement, j'ai vu que OVH, en tant que <a href="http://fr.wikipedia.org/wiki/Registre_de_noms_de_domaine">registrer</a> (chez qui on achète ses noms de domaine), proposait de configurer directement des entrées DNS Dynamique.</p>
+
+<p>Option plutôt sympathique il faut l'avouer, ça permet de gérer facilement ses noms de domaine avec IP dynamique. Quelques limitations sont à prévoir, notamment au niveau de la mise à jour de l'enregistrement. On est là pour en parler&nbsp;:-)</p>
+
+<p>&nbsp;</p>
+
+## C'est quoi un DNS Dynamique ?
+
+<p>Un DNS dynamique, c'est en fait un DNS classique, mais avec un temps de réplication et de cache (<a href="http://fr.wikipedia.org/wiki/Time_to_Live">TTL</a>) très court.</p>
+
+<p>Ceci, associé à un logiciel spécifique installé chez le client, permet d'avoir un nom de domaine qui se met à jour très rapidement à l'échelle mondiale. Cela permet notamment de gérer facilement lorsque vous avez besoin de joindre quelque chose chez vous (NAS, PC en VNC, auto-hébergement, ...) et que vous avez un FAI qui ne vous donne qu'une IP dynamique, c'est à dire qui change régulièrement.</p>
+
+<p>En mettant à jour votre nom de domaine en DNS Dynamique dès que votre adresse IP change, cela permet d'avoir un temps d'indisponibilité assez court, à n'importe quel moment. En plus, ça se fait souvent en automatique.</p>
+
+<p>C'est un système un peu batard né de l'utilisation du NAT et des IP privées, et nécessaire à cause des FAI trouvant plus simple de vous changer d'IP plutôt que de vous en filer une fixe. (On se demandera à jamais pourquoi)</p>
+
+## Une bonne idée, mais...
+
+<p>Bon, les définitions étant posées, parlons maintenant plus particulièrement du service d'OVH.</p>
+
+<p>Proposer des DNS dynamiques, c'est bien, mais comme vu plus haut, ça nécessite une interaction côté client pour mettre à jour en temps réel (idéalement) l'entrée DNS.</p>
+
+<p>Pour cela, OVH propose dans sa documentation divers logiciels à installer chez vous qui se chargent du boulot. Windows et Linux sont au rendez vous, mais malheureusement, la plupart de ces logiciels sont fait pour être installés sur votre PC perso, voir un serveur maison.</p>
+
+<p>De plus, ils sont pour la plupart basés sur le fait que votre PC perso/votre serveur porte l'IP publique dynamique, ce qui est quand même très rare. (BiduleBox powaa !)</p>
+
+<p>On peut s'en sortir avec un vérificateur d'adresse IP externe.</p>
+
+<p>Mais la grosse limitation intervient lorsque l'on veut configurer cette mise à jour directement sur un routeur (accessoirement une BiduleBox). Ce qui est plus logique, puisque ce sont souvent eux qui portent l'IP publique dynamique.</p>
+
+<p>Or, à moins que votre routeur propose directement de profiter du service OVH, vous allez devoir utiliser une URL HTTP pour faire cette mise à jour. Et ça, point de trace sur la documentation OVH, ni sur les forum, malgré quelques post courageux de personnes bien intentionnées.</p>
+
+<p>&nbsp;</p>
+
+## L'exemple du WRT54GL Tomato
+
+<p>J'utilise pour ma part un routeur <a href="http://fr.wikipedia.org/wiki/WRT54GL">Linksys WRT54GL</a>, excellent produit, avec le firmware <a href="http://www.polarcloud.com/firmware">tomato</a>. Bien qu'assez riche en option pour configurer le DNS dynamique, ce firmware ne propose pas par défaut OVH. (Ni d'ailleurs aucun firmware WRT54GL à ma connaissance)</p>
+
+<p>Ce firmware propose toutefois d'entrer une URL personnalisée pour aller mettre à jour votre enregistrement DNS. Plutôt sympathique, encore faut-il connaitre cette URL. Comme OVH n'en parle pas, il faut chercher.</p>
+
+<p>Pour ma part, j'ai du regrouper plusieurs sites/blog en parlant pour réussir à obtenir une URL utilisable, je vous la fournit donc, après tout c'est l'info que vous cherchiez en venant ici&nbsp;;-)</p>
+
+<p>Donc, dans le menu Basic -&gt; DDNS -&gt; Dynamic DNS 1 :</p>
+
+<ul>
+	<li>Choisir dans le menu déroulant Custom URL</li>
+	<li>Entrer l'URL suivante : <u><strong>http://IDENTIFIANT:MOTDEPASSE@www.ovh.com/nic/update?system=dyndns&amp;hostname=NOMDEDOMAINE&amp;myip=@IP</strong></u></li>
+</ul>
+
+<p>Où :&nbsp;</p>
+
+<ol>
+	<li>IDENTIFIANT est l'identifiant de gestion du DNS dynamique configuré dans l'interface OVH</li>
+	<li>MOTDEPASSE est le mot de passe de cet identifiant</li>
+	<li>NOMDEDOMAINE est le nom de domaine à mettre à jour</li>
+	<li>@IP est le mot clé de tomato pour récupérer la nouvelle IP publique</li>
+</ol>
+
+<p>N'oubliez pas de modifier dans le premier menu déroulant l'option que vous souhaitez :</p>
+
+<ul>
+	<li>WAN IP si votre routeur porte l'IP publique</li>
+	<li>External IP checker si votre routeur est derrière une BiduleBox</li>
+	<li>Custom IP si vous êtes en IP fixe, mais là l'intérêt est quand même moindre...</li>
+</ul>
+
+<p>Cochez "Force next update" pour que la mise à jour se fasse tout de suite, puis cliquez sur "Save".</p>
+
+<p>La mise à jour va s'effectuer, et si tout va bien mettre à jour le DNS sans erreurs.</p>
+
+<p>Voila, en espérant que ça serve à quelqu'un dans le meilleur des mondes&nbsp;</p>

content/Système/configurer-reverse-proxy-apache.md

@@ -0,0 +1,303 @@
+Title: Configurer un reverse proxy Apache
+subtitle: (HTTP/HTTPS)
+Date: 2012-10-16 20:06
+Modified: 2012-10-16 20:06
+Tags: reverse proxy, apache, debian, linux, nom de domaine
+keywords: reverse proxy, apache, debian, linux, nom de domaine
+Slug: configurer-reverse-proxy-apache
+Authors: Victor
+Status: published
+
+[TOC]
+
+## Ou : routage entre serveurs par nom de domaine
+
+<p>Et oui, c'est ce dont on va parler ici. Comme ce n'est peut être pas très clair pour tout le monde, je vais me permettre une toute petite digression pour expliquer ce qu'est le routage, et plus précisément ce que j'appelle le routage par noms de domaine.</p>
+
+## Merci pour cette digression.
+
+<p>Mais de rien.</p>
+
+<p>Qu'est ce que le <a href="http://fr.wikipedia.org/wiki/Routage">routage</a> ? Ca consiste à se servir d'une unique machine (comunément appelée "le routeur") pour diriger des flux réseau vers différents autres matériels.</p>
+
+<p>Ca sert le plus simplement du monde sur Internet, pour router les différents sous réseaux. Vous voulez joindre truc.truc.truc.truc, mais vous avez comme IP machin.machin.machin.machin, alors un routeur va pouvoir vous dire :</p>
+
+<p>"Pour aller vers truc, c'est à gauche, mais si c'est pour aller vers bidule, c'est à droite. Quand à toi machin, tu es au milieu".</p>
+
+<p>Ok, c'est résumé très vite pour les puristes, mais l'idée est là&nbsp;:-)</p>
+
+<p>Il existe différents autres types de routage. On utilise ce terme parce que l'idée de donner des routes (ou des chemins) pour diriger des flux reste la même.</p>
+
+<p>Une machine (routeur, PC, serveur, ...) reçoit un flux, et à partir de différents critères choisit de rediriger ce flux vers un autre matériel du réseau, l'objectif final étant bien sûr que ce flux arrive à destination de manière sûre.</p>
+
+## Ca suffit oui ?
+
+<p>On y arrive.&nbsp;;-)</p>
+
+<p><strong>EDIT décembre 2015 : </strong>j'ai écris un <a href="http://blog.héry.com/article21/configurer-un-reverse-proxy-sous-haproxy">nouvel article</a> pour utiliser haproxy en tant que reverse-proxy, logiciel plus léger et plus adapté qu'apache à cet usage.</p>
+
+<p>Or donc, si vous avez plusieurs serveurs web mais une seule connexion Internet, alors vous avez sans doute déjà eu cette problématique.</p>
+
+<p><em>Comment joindre plusieurs sites web sur différents serveurs depuis les Internet ?</em></p>
+
+<p>La solution qui s'impose directement, c'est du routage de port.</p>
+
+<p>Ce routage particulier consiste à router différents flux reçus depuis Internet vers des machines à l'intérieur de votre réseau local en se basant sur les ports réseaux utilisés. Ce n'est pas le lieu pour décrire un port réseau. Voyez ça comme une porte. Vous rentrez dans la même maison, mais selon que vous utilisiez la porte d'entrée ou la véranda, vous êtes "redirigés" vers une pièce différente de la maison.</p>
+
+<p>&nbsp;</p>
+
+<p>Ce type de routage présente un inconvénient certain : chacun de vos utilisateurs doit spécifier la porte qu'il veut utiliser pour joindre le bon serveur.</p>
+
+<p>En général, ça consiste à taper <em>nomdedomaine.tld:port </em>dans votre navigateur, ce qui n'est pas très pratique, et difficile à expliquer à vos clients. (Et oubliez de suite expliquer ça à Google and co)</p>
+
+<p>C'est là qu'intervient ce super outil, le <a href="http://fr.wikipedia.org/wiki/Reverse_proxy">reverse proxy, ou mandataire inverse</a>. Nous allons voir ici comment l'utiliser avec <a href="http://www.apache.org/">Apache</a>, un serveur web populaire. Il est sans doute possible de le faire également avec NGinX ou lightHTTPD, mais ce n'est pas le sujet&nbsp;:-D</p>
+
+<p>Le mandataire inverse va regarder le site que vous voulez joindre, et vous rediriger vers le bon serveur directement. Il servira ensuite d'intermédiaire sur le réseau entre vous et le serveur.</p>
+
+## On veut du concret !
+
+<p>Voila voila !</p>
+
+### Pré-requis matériel
+
+<p>Pour commencer, il va falloir définir un serveur mandataire. C'est sur ce serveur que nous allons configurer le mandataire inverse.</p>
+
+<p>Il peut héberger lui-même des sites Internet, ou vous pouvez l'utiliser uniquement comme mandataire, ça n'a pas d'importance. Si vous utilisez cette solution à des vues industrielles, mieux vaut prévoir un serveur robuste, puisqu'il supportera toutes les requêtes vers tous vos sites web.</p>
+
+<p>Ensuite, il vous faut configurer votre routeur/machinbox© pour rediriger tout le flux web (port 80) vers le serveur mandataire. Ceci se fait grâce à un routage de port classique. Toutes les requêtes web arriveront maintenant sur ce serveur, qui va décider quoi en faire.</p>
+
+<p>En théorie on devrait pouvoir faire la même chose pour l'HTTPS, mais vu qu'il y a quand même des contraintes de certificats et que je n'ai pas testé, je préfère ne pas dire de bêtises ici.</p>
+
+### Prérequis logiciel
+
+<p>Là, c'est simple. Il vous faut un serveur Apache installé et fonctionnel sur votre serveur mandataire. C'est tout. Un système de pare-feu ne serait également pas de trop (ce serveur est l'unique point d'entrée d'Internet, rappelons le :-) )</p>
+
+<p>Il vous faut également (bien evidemment ?) une connexion ssh vers votre serveur, ou à défaut un écran-clavier-souris.</p>
+
+## Plongeons dans le cambouis
+
+### Activation du module proxy Apache
+
+<p>Connectez vous sur votre serveur (mandataire), puis tapez :</p>
+
+<pre>
+$ sudo a2enmod proxy
+
+$ sudo a2enmod proxy_http</pre>
+
+<p>&nbsp;</p>
+
+<p>Redémarrez ensuite Apache un petit coup</p>
+
+<pre>
+$sudo /etc/init.d/apache restart</pre>
+
+<p>&nbsp;</p>
+
+<p>Voila, c'est fait !</p>
+
+### Configuration du routage
+
+<p>Ici, tout va se faire grâce au système d'hôte virtuel Apache.</p>
+
+<p>Editez un fichier dans /etc/apache2/site-available/</p>
+
+<pre>
+$ sudo nano /etc/apache2/sites-available/monsite</pre>
+
+<p>&nbsp;</p>
+
+<p>Puis configurez votre hôte comme suit :</p>
+
+<pre>
+&lt;VirtualHost *:80&gt;
+#
+ServerName nomdedomaine.tld #
+ProxyPreserveHost On
+ProxyRequests off
+ProxyPass / http://IPSERVEURWEBINTERNE/
+ProxyPassReverse / http://IPSERVEURWEBINTERNE/
+#
+&lt;/VirtualHost&gt;</pre>
+
+<p>&nbsp;</p>
+
+<p>Cela va permettre de rediriger toutes les requêtes sur nomdedomaine.tld en http vers le serveur IPSERVEURWEBINTERNE</p>
+
+<p>&nbsp;</p>
+
+<p>C'est simple et efficace. Vous pouvez créer toutes vos autres redirections dans ce fichier, ou créer un fichier par redirection (plus propre mais plus contraignant). A vous de voir.</p>
+
+<p>Une fois ces fichier créés, il vous faut activer les hôtes virtuels.</p>
+
+<p>Faites</p>
+
+<pre>
+$ sudo a2ensite monsite
+</pre>
+
+<p>pour chaque fichier que vous avez créé.</p>
+
+<p>&nbsp;</p>
+
+<p>Ensuite, rechargez la configuration Apache (pas besoin de redémarrer)</p>
+
+<pre>
+$ sudo /etc/init.d/apache2 reload</pre>
+
+<p>&nbsp;</p>
+
+## Tadam !
+
+<p>Il ne vous reste plus qu'à tester. De l'exterieur, essayez de joindre nomdedomaine.tld, tout doit fonctionner :-)</p>
+
+<p>Et voila, vous avez économisé plein d'adresses IP publiques ! Mais pourquoi utiliser plusieurs serveurs Web derrière une seule IP petits coquinous ? Ça, ça vous regarde...</p>
+
+<p>Si jamais j'ai la problématique un jour, je configurerai ça pour de l'HTTPS (mais honnêtement j'espère jamais&nbsp;:-D )</p>
+
+<p>&nbsp;</p>
+
+<p><s>Et dans ce cas je rajouterai ça sur le blog, promis !&nbsp;</s> Voir juste au dessous !</p>
+
+## Edit : Comme promis, la version https
+
+<p>Et oui, car finalement j'ai du m'y mettre :)</p>
+
+<p>Tout d'abord, les limitations. Je n'ai réussit jusqu'alors qu'à configurer une connexion HTTPS entre le client et le reverse proxy.</p>
+
+<p>Je n'ai pas réussit à avoir ensuite de l'HTTPS entre le reverse proxy et le vrai serveur web, ce qui veut dire que, au moins sur le réseau local, les données transitent en clair.</p>
+
+<p>De mon point de vue ce n'est qu'un problème conceptuel, étant donné que le "réseau local" est en fait une liaison directe entre machines virtuelles sur le même hyperviseur, donc bon. Mais quand même, ce n'est pas très propre. Si jamais quelqu'un a une suggestion à ce sujet, qu'il me fasse signe :)</p>
+
+<p>&nbsp;</p>
+
+<p>L'idée donc du reverse proxy en HTTPS, c'est que c'est le proxy qui va contenir les certificats https. Celui-ci va alors répondre à la place du serveur web, avec la bonne URL puique c'est un proxy, et transmettre ensuite les requêtes vers le serveur.</p>
+
+<p>On a donc un schéma dans cette idée :</p>
+
+<p>&lt;Client&gt; ====https====&lt;Proxy&gt;----http----&lt;serveur web&gt;</p>
+
+<p>Et en plus, c'est assez simple en fait.</p>
+
+<p><strong>On considérera ici que vous avez déja généré des certificats propres pour votre site (éventuellement auto-signés).</strong></p>
+
+<p>Il vous faudra activer le SSL sur votre reverse proxy :&nbsp;</p>
+
+<pre>
+$ sudo a2enmod ssl
+$ sudo /etc/init.d/apache2 restart
+</pre>
+
+<p>Ensuite, placez vos certificats (clef publique, clef privée) dans le dossier /etc/apache2/ssl/.</p>
+
+<pre>
+$ sudo cp moncertificat.* /etc/apache2/ssl/
+</pre>
+
+<p>Créez l'hôte virtuel qui servira pour votre redirection :</p>
+
+<pre>
+sudo nano /etc/apache2/site-available/monproxySSL
+</pre>
+
+<p>Et remplissez le avec ceci :</p>
+
+<pre>
+	&lt;VirtualHost *:443&gt;
+
+	# Décommentez cette ligne et indiquez-y l'adresse courriel de l'administrateur du site
+	#ServerAdmin webmaster@my-domain.com
+
+	# Classique, votre nom de domaine
+	ServerName monsite.tld
+
+	# Si jamais vous avez d'autres domaines renvoyant sur ce site, utilisez la dircetive ServerAlias
+	# Vous pouvez utiliser le joker * pour prendre en compte tout les sous-domaines
+	#ServerAlias www2.my-domain.com www.my-other-domain.com *.yet-another-domain.com
+
+	# L'emplacement des logs.
+	ErrorLog /var/log/apache2/monsite.tld-error.log
+	LogLevel warn
+	CustomLog /var/log/apache2/monsite.tld-access.log combined
+
+	# SSL magic
+	#
+	# Il est nécessaire d'activer SSL, sinon c'est http qui sera utilisé
+	SSLEngine On
+
+	# On autorise uniquement les clefs de cryptage longue (high) et moyenne (medium)
+	# SSLCipherSuite HIGH:MEDIUM
+
+	# On autorise SSLV3 et TLSv1, on rejette le vieux SSLv2
+	# SSLProtocol all -SSLv2
+
+	# La clef publique du serveur :
+	SSLCertificateFile /etc/apache2/ssl/moncertificat-cert.pem
+
+	# La clef privée du serveur:
+	# SSLCertificateKeyFile /etc/apache2/ssl/moncertificat-key.pem
+
+	# Theses lines only apply of the rewrite module is enabled.
+	# This is a security enhancement recommanded by the nessus tool.
+	&lt;IfModule mod_rewrite.c&gt;
+	RewriteEngine on
+	RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
+	RewriteRule .* - [F]
+	&lt;/IfModule&gt;
+	&lt;IfModule mod_rewrite.c&gt;
+	&lt;IfModule mod_proxy.c&gt;
+
+	#Ne commentez jamais cette ligne, elle évite que votre serveur soit utilisé comme proxy par des gens mal-intentionnés.
+	ProxyRequests Off
+
+	# Cetet option passe les nom d'hôte au serveur, ce qui vous permet d'utiliser également des hôtes virtuels sur le serveur principal.
+	ProxyPreserveHost On
+
+	# Les lignes classiques de proxy. Comme dit au dessus, on passe le flux en http.
+	ProxyPassReverse / http://IPSERVEURWEB/
+	RewriteRule ^/(.*) http://IPSERVERUWEB/$1 [P,L]
+
+	&lt;/IfModule&gt;
+	&lt;/IfModule&gt;
+
+	# Autoriser l'accès au contenu à travers le proxy.
+	#Ne l'enlevez pas si vous voulez que le site fonctionne !
+	&lt;Location /&gt;
+	Order deny,allow
+	Allow from all
+	&lt;/Location&gt;
+
+	&lt;/VirtualHost&gt;
+
+
+	&lt;VirtualHost *:80&gt;
+	# Cette partie va permettre de rediriger d'éventuelles requêtes en HTTP vers l'HTTPS
+	# Vous pouvez également configurer le proxy à la place de la règle de réécriture si vous voulez autoriser l'accès en HTTP
+	ServerName monsite.tld
+
+	#ServerAlias www2.my-domain.com www.my-other-domain.com *.yet-another-domain.com
+
+	# Theses lines only apply of the rewrite module is enabled.
+	# This is a security enhancement recommanded by the nessus tool.
+	&lt;IfModule mod_rewrite.c&gt;
+	RewriteEngine on
+	RewriteCond %{REQUEST_METHOD} ^{TRACE|TRACK}
+	RewriteRule .* - [F]
+	&lt;/IfModule&gt;
+
+	# On renvoit toutes les requêtes HTTP vers l'HTTPS.
+	Redirect permanent / https://monsite.tld/
+
+	&lt;/VirtualHost&gt;
+</pre>
+
+<p>N'oubliez pas bien sûr d'activer votre nouvel hôte virtuel :</p>
+
+<pre>
+$ sudo a2ensite monproxyssl
+$ sudo /etc/init.d/apache2 reload
+</pre>
+
+<p>Et voila, votre reverse proxy doit fonctionner en HTTPS :)</p>
+
+<p>&nbsp;</p>

content/Système/virtualisation-opensource-qui-roxx-proxmox.md

@@ -0,0 +1,167 @@
+Title: La virtualisation open source qui roxx
+subtitle: ; Proxmox
+Date: 2012-09-04 20:00
+Modified: 2012-09-04 20:00
+Tags: debian, proxmox, linux, virtualisation
+keywords: debian, proxmox, linux, virtualisation
+Slug: virtualisation-opensource-qui-roxx-proxmox
+Authors: Victor
+Status: published
+
+[TOC]
+
+## Proxmox, kesaco ?
+
+<p>Comme je l'ai dit dans un précédent <a href="http://blog.héry.com/article7/la-virtualisation-ou-l-un-des-seul-bienfait-du-cloud">article sur la virtualisation</a>, je trouve cette manière de fonctionner sur un serveur particulièrement intéressante.</p>
+
+<p>Comme je l'ai également dit à la fin de cet article, j'utilise pour ma part un outil de virtualisation open source nommé <a href="http://www.proxmox.com/">proxmox</a>.</p>
+
+<p><img alt="Logo Proxmox" src="/images/proxmox_logo.png" style="width: 195px; height: 28px" /></p>
+
+<p>&nbsp;</p>
+
+<p>Proxmox est un packaging disponibles pour de nombreuses versions de linux/unix, mais il existe une distribution basée sur debian et maintenue par Proxmox, que j'utilise pour sa simplicité et sa compatibilité. (Au moins, pas besoin de se demander si tel ou tel module noyau fonctionnera ou pas une fois installé le package proxmox...)</p>
+
+<p>Donc, la distribution debian Proxmox vous permet, une fois installée, de virtualiser via 2 techniques, OpenVZ et KVM, et de gérer toutes vos machines simplement via une interface web, de les sauvegarder en masse de manière programmée, tout en ayant un panel d'outils en ligne de commande sympathiques pour faire tout et n'importe quoi.</p>
+
+<p>Il est également possible de mettre en place un cluster entre plusieurs Proxmox, d'accéder aux VM via l'interface web avec une applet Java, etc etc.</p>
+
+<p>&nbsp;</p>
+
+<p>Je vais donc détailler dans cet articles les fonctionnalités de Proxmox, parce que j'ai bien envie d'en parler :)</p>
+
+## Proxmox, réseau bridgé
+
+<p>Avec proxmox, vous êtes automatiquement lié à différentes interfaces "bridgées". Ou plutôt, des <a href="http://fr.wikipedia.org/wiki/Pont_(informatique)">interfaces de pont</a> en français. En gros, un switch virtuel dans le serveur.</p>
+
+<p>C'est assez classique des hyperviseur, mais ça vaut le coup de le rappeller. Ca permet de lier les interfaces réseau des VM aux interfaces réseau physiques de l'hyperviseur, pour par exemple leur donner accès à Internet.</p>
+
+<p>Ca permet également de créer des interfaces bridgés pour créer un réseau interne dans le serveur, permettant de joindre en interne toutes les VM. Totalement étanche à l'extérieur, ça ouvre des possibilités intéressantes en matière de service sécurisés&nbsp;:-)</p>
+
+<p>L'utilisation de ce service permet vraiment de configurer tout et n'importe quoi de manière très simple. En effet vous pouvez ajouter de nombreuses interfaces à un bridge, par exemple des tap/tun pour openVPN, des interfaces dummy ou même d'autre bridges !</p>
+
+<p>De plus, vous pouvez grâce à iptables créer des règles spécifique sur cette interface, pour la rendre totalement étanche, comme un vrai switch physique.</p>
+
+<p>C'est sur ce principe qu'est basé le système réseau de proxmox, et il est vraiment très simple à utiliser et à exploiter.</p>
+
+<p>&nbsp;</p>
+
+## Containeurs OpenVZ, ou chroot en force
+
+<p><a href="http://openvz.org"><img alt="Logo OpenVZ" src="/images/800px-openvz-logo.png" style="width: 200px; height: 50px" /></a></p>
+
+### Quoique c'est ?
+
+<p>Bon, soit vous êtes admin système et vous avez compris le titre, soit non. Dans mon métier, on aime les trucs binaires !</p>
+
+<p>La virtualisation Open VZ va en fait consister à se servir du noyau système de l'hyperviseur pour faire fonctionner les machines virtuelles.</p>
+
+<p>Cela a plusieurs effets, positifs comme négatifs.</p>
+
+<p>En fait, vos machines virtuelles vont tourner en utilisant les ressources de base de l'hyperviseur. Contrairement à d'autres type de virtualisation, un OpenVZ va ainsi partager ses ressources directement avec l'hyperviseur.</p>
+
+<p>Concrètement, si cela permet d'utiliser différentes distributions linux dans vos machines virtuelles, vous ne pourrez pas utiliser de Windows. Toutes vos distributions seront basées sur le noyau de l'hyperviseur, c'est à dire un noyau linux.</p>
+
+<p>Installer un système Open VZ revient à choisir un "template", sorte d'image d'un véritable système d'exploitation, qui va être utilisé pour simuler ce système à destination de la machine virtuelle. De cette façon, du point de vue de la machine, le système sera correct et normal.</p>
+
+<p>Ensuite, en se basant sur ce template, l'hyperviseur va réaliser un gros "<a href="http://fr.wikipedia.org/wiki/Chroot">Chroot</a>". Pour les néophytes ayant la flemme de lire wikipédia, l'hyperviseur va créer un dossier ayant une arborescence linux classique, puis va lancer la VM comme un processus classique en lui disant que son dossier racine / va être l'arborescence précedemment créée.</p>
+
+<p>En conséquence, tout les processus lancées dans la VM seront vus depuis l'hyperviseur, alors que la VM sera une machine à part entière.</p>
+
+### osef non ?
+
+<p>Ben non, ça amène pas mal d'avantages intéressants.</p>
+
+<ul>
+	<li>La VM a un nouveau nom. On appelle ça un containeur (CT), et c'est plus classe</li>
+	<li>Le CT n'a pas vriament besoin de démarrer ou redémarrer, vu que c'est un processus. Donc, quand on démarre ou redémarre un containeur, ça dure approximativement 10 secondes. (Sans SSD !!)</li>
+	<li>Le CT partage pas mal de configuration noyau avec l'hyperviseur. La gestion du swap ou de la RAM par exemple</li>
+	<li>Le CT n'a pas besoin d'un certain nombre de service (jamais de client NTP dans un CT !)</li>
+	<li>Le CT consomme extrêmement peu de ressource, même avec de l'apache, du mysql et autre (à charge raisonnable bien sûr...)</li>
+	<li>Le CT peut utiliser du réseau bridgé, ou entièrement virtualisé (plus d'adresse MAC nécessaire)</li>
+	<li>On peut facilement imaginer plusieurs centaines de CT sur un serveur sans trop de problème.</li>
+	<li>Comme l'intérieur des CT sont des dossier de l'hyperviseur, on peut modifier, sauvegarder et récupérer très simplement le contenu des CT.</li>
+	<li>On peut à n'importe quel moment augmenter en temps réel la taille du disque dur allouée au CT, même si celui est en fonctionnement.</li>
+</ul>
+
+<p>Il y a surement plein d'autres choses, mais globalement c'est déjà des points très intéressants, selon les usages qu'on en a.</p>
+
+<p>Par contre, comme d'habitude, il y a aussi quelques inconvénients. Le noyaux étant émulé, il y a des choses qui ne fonctionnent pas dans le CT.</p>
+
+<ul>
+	<li>N'essayez jamais d'installer un client NTP. Le CT fonctionne avec celui de l'hyperviseur, et il peut y avoir méchant conflit</li>
+	<li>Au revoir certains modules noyaux particulier, notamment IPSec...</li>
+	<li>Les machines virtuelles java n'aiment pas trop OpenVZ (sauf l'obscure machine d'IBM) Donc, pas de java sur OpenVZ (&lt;troll&gt;Des failles de sécurité en moins ! &lt;/troll&gt;)</li>
+	<li>Il faut activer des choses depuis l'hyperviseur pour utiliser OpenVPN dans un CT (mais une fois fait, ça marche nickel)</li>
+	<li>La gestion du swap, de la RAM sont basés sur la configuration de l'hyperviseur. Enfin, ce n'est pas forcément un inconvénient</li>
+	<li>Il y a souvent des manip' un peu particulière à faire pour utiliser des services touchant au matériel ou au noyau, mais là encore on s'en tire</li>
+</ul>
+
+<p>&nbsp;</p>
+
+<p>Bref, il y a du pour et du contre. Perso, sauf pour certains usages très précis (IPSec ou tomcat avec Java...), je n'utilise que des CT sous OpenVZ. Optimisées et ultra rapides, ça serait vraiment dommage de s'en passer.</p>
+
+<p>&nbsp;</p>
+
+## KVM, le mode de secours
+
+<p><img alt="Logo KVM" src="/images/kvmbanner-logo2.png" style="width: 200px; height: 62px" /></p>
+
+<p>Bon, si vous tenez vraiment à faire tourner tomcat, à utiliser IPSec, voir à installer un client NTP. Ou pire, que vous n'aimez pas OpenVZ ou que vous tenez à utiliser Windows (ouh ! Haro !), proxmox n'a pas mis tous les oeufs dans le même panier et propose un deuxième système de virtualisation open source, j'ai nommé <a href="http://www.linux-kvm.org/page/Main_Page">KVM</a>.</p>
+
+<p>Une machine KVM est cette fois une véritable machine virtuelle, complètement indépendante de l'hyperviseur. Elle possède son propre noyau, ses propres interfaces réseaux et sa carte graphique, un disque dur bien défini, etc.</p>
+
+<p>Vous pouvez donc tout à fait l'utiliser pour faire tourner un système Windows si vous le souhaitez.</p>
+
+<p>Cette technique de virtualisation est robuste, mais aucun des avantages d'OpenVZ ne peut être appliqué à elle. En contrepartie, la plupart des inconvénients d'OpenVZ n'a pas de prise sur une KVM&nbsp;:-)</p>
+
+<p>Etant une "vraie" machine, une KVM va pouvoir utiliser ses propres modules noyaux (bonjour, IPSec), ainsi qu'une machine virtuelle java. On l'installe depuis une image iso classique, comme n'importe quel système d'exploitation.</p>
+
+<p>Pour ma part, je ne m'éteindrai pas trop dessus, car je n'utilise les KVM que si mon besoin ne peut vraiment pas se poser sur OpenVZ.</p>
+
+<p>KVM est certes plus complet, mais par rapport à OpenVZ, le fait d'avoir une vraie machine à émuler est aussi beaucoup plus lourd. Ca demande plus de ressource à l'hyperviseur, c'est bien plus long à éteindre et démarrer qu'un containeur, on est obligé d'y accéder via SSH ou avec les outils proxmox, ...</p>
+
+<p>Bref&nbsp;:-)</p>
+
+<p>&nbsp;</p>
+
+## Interface web, le bonus qui en jette
+
+<p>Bon, je ne vous ferait pas plein de screens super bô de l'interface web de gestion proxmox.</p>
+
+<p>Accessible nativement en https (c'est le bien), elle permet de quasiment tout gérer pour vos tâches quotidienne.</p>
+
+<ul>
+	<li>Création de machines virtuelles en 3 clics (OpenVZ et KVM)</li>
+	<li>Modifications des ressources allouées à ces machines (RAM, disques, nombres d'interfaces réseau, ...)</li>
+	<li>Gestion des stockages (disques dur machines, images iso, templates OpenVZ, ...)</li>
+	<li>Management des machines (éteindre, démarrer, couper à chaud ou à froid, accès à une console VNC ou un shell)</li>
+	<li>Création de cluster entre différents serveurs proxmox</li>
+	<li>Mise en place de <a href="http://fr.wikipedia.org/wiki/Haute_disponibilité">Haute Disponibilité</a> (un peu de ligne de commande nécessaire selon les configurations)</li>
+	<li>Gestion de TOUTES les machins d'un cluster depuis UNE seule interface web (trop le pied !)</li>
+	<li>Gestion d'utilisateurs, de groupes d'utilisateurs, de droits d'accès à des machines (qui a dit "Vendons du <a href="http://blogvps.kicou.org/">VPS</a> !")</li>
+	<li>Gestion de l'hyperviseur lui-même (redémarrage, accès shell, monitoring du traffic réseau, de la charge processeur, de la RAM, du SWAP, du...)</li>
+	<li>Gestion des sauvegardes, journalières, mensuelles, incrémentales, ...</li>
+	<li>Gestion du stockage réseau, du stockage local, de l'iscsi</li>
+	<li>...</li>
+</ul>
+
+<p>GLobalement, avec simplement l'interface web, vous faites tourner tout un tas de machines virtuelles seulement en cliquant 2 ou 3 fois, depuis une interface web sécurisée.</p>
+
+<p>En rajoutant un peu de ssh et de ligne de commande, vous avez un service pro, redondé, sécurisé, permettant de lancer votre propre service de VPS dans votre salon si vous avez envie ! Après bien sûr, à vous de négocier votre bande passante avec votre FAI (ainsi qu'avec ses <a href="http://wiki.auto-hebergement.fr/fournisseurs/fai">Conditions Générales de Vente</a>)</p>
+
+<p>&nbsp;</p>
+
+<p>A plus petite échelle (la mienne par exemple) vous pouvez simplement sauvegarder et redémarrer votre serveur web que vous avez pris 3 jours de temps libre à configurer aux petits oignons. (Enfin, surtout le serveur courriel en fait...), et ce même si votre serveur maison claque brusquement.</p>
+
+<p>&nbsp;</p>
+
+## Moi, je suis convaincu (sinon j'en ferai pas la pub)
+
+<p>Auneffet, ce en quoi je crois, j'en parle. Simple et efficace&nbsp;:-)</p>
+
+<p>Maintenant, ce long article servant d'introduction à d'autres prévus sur la configuration de proxmox, j'espère que vous l'aurez apprécié.</p>
+
+<p>Désolé, c'est long. Mais c'est bon aussi&nbsp;;-)</p>
+
+<p>&nbsp;</p>

content/comments/configurer-reverse-proxy-apache/0.md

@@ -0,0 +1,41 @@
+email: sebastienfct@gmail.com
+date: 2014-11-06T20:00+01:00
+author: SebFCT
+website:
+
+Bonjour,
+
+J'ai suivi ton tutoriel (très clair au passage) afin de tenter de gérer les problème que je rencontre en ce moment, mais sans résultat..
+
+Pour faire court, j'utilise un serveur proxmox qui contient plus conteneurs (dont ceux qui m'intéressent: CT101 et CT102).
+
+CT101 et CT102 sont tous deux des conteneur debian avec l'installation de base d'un site web (apache, php, ...).. Ils sont affichés respectivement lorsque je tape X.Y.Z.W:80 et X.Y.Z.W:8765 (X.Y.Z.W étant l'adresse de mon serveur).
+
+J'ai loué deux nom de domaine, j'aimerai les liés à chacun des conteneurs. J'ai donc rajoutés
+
+
+    <VirtualHost *:80>
+
+    ServerName domaine1.com
+    ProxyPreserveHost On
+    ProxyRequests off
+    ProxyPass / http://X.Y.Z.WW:80/
+    ProxyPassReverse / http:/X.Y.Z.W:80/
+
+    </VirtualHost>
+
+    <VirtualHost *:80>
+
+    ServerName domaine2.com
+    ProxyPreserveHost On
+    ProxyRequests off
+    ProxyPass / http://X.Y.Z.WW:8765/
+    ProxyPassReverse / http:/X.Y.Z.W:8765/
+
+    </VirtualHost>
+
+Au final le domaine1.com et le domaine2.com affichent tout les deux les meme contenu (celui du CT101). Par contre en ajoutant le bon port (celui attribué pour le CT102) tout fonctionne, mais bon.. on revient au problème soulevé sur tes première lignes d'article...
+
+Une idée du problème dans ma démarche?
+
+Merci d'avance!

content/comments/configurer-reverse-proxy-apache/1.md

@@ -0,0 +1,31 @@
+email: courriel@victor-hery.com
+date: 2014-11-07T11:51+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 0md
+
+Hello SebFCT,
+
+Ta configuration à l'air correcte, le problème vient peut être plutôt de l'endroit où tu la mets.
+
+L'idée d'un reverse proxy est d'avoir un 3eme serveur devant les 2 autres capable de gérer les requêtes, ou au pire que l'un des 2 serveur serve de proxy.
+
+Cela impose que les DNS de tes domaines pointent sur ce serveur de proxy, ce qui semble bien être ton cas vu que domaine1 et domaine2 semblent arriver dessus.
+
+Par contre, avec ta conf, le proxy ne devrait écouter que sur le port 80, et donc le port 8765 devrait être fermé et renvoyer une erreur.  
+Or ça n'a pas l'air d'être le cas, si domaine2.com:8765 répond.
+
+A première vue, ça me donne 2 idées :
+ - Ton proxy tourne sur CT102, où le port 8765 écoute
+ - Ou ta redirection de port depuis ton Ip publique (si tu en a une seule ?) fait que ce port écoute toujours depuis l'extérieur, et la redirection du port 80 elle redirige uniquement vers CT101 (et pas vers le proxy)
+
+Dans le premier cas, il faudrait enlever le proxypass. Sur CT102, tu n'aurais besoin que d'écouter sur le port 80, correctement pour domaine2, et avec proxy pour domaine1
+
+Dans le deuxième cas, il faudrait corriger ta redirection de port pour que le port 80 soit redirigé vers ton proxy, afin que ce soit lui qui gère bien les requêtes.
+
+3eme cas peut être, ton proxy tourne directement sur le serveur avec l'IP physique, MAIS, il y a toujours une redirection du port 80 vers CT101 ? Dans ce cas, la redirection de port prendra la priorité sur apache (puisque traité à une couche en dessous), donc il te faudra l'enlever pour que le proxy prenne la main.
+
+Ce sont les quelques idées de problèmes qui me viennent avec ta description.  
+Si a priori ce n'est pas clair (ou incorrect), n'hésite pas à me préciser la configuration, surtout physique :) (ou est le proxy, etc)
+
+A bientôt

content/comments/configurer-reverse-proxy-apache/10.md

@@ -0,0 +1,10 @@
+email: abma1@orange.fr
+date: 2015-03-15T08:24+01:00
+author: batam
+website:
+
+Bonjour,voilà mon probleme:  
+j'ai un site principal que je vais appeler monsite.com dont les fichiers se trouvent dans le répertoire /var/www/monsite.com.  
+je veux donner accès à une personne tierce en lui atrribuant un nom par exemple monpetitsite, mais je veux que cette personne n'ait pas accès au repertoire  /var/www, pour cela je veux lui laisser un accès complet dans un autre répertoire par exemple /home/user  
+ et lui créer un raccourci dans /var/www sans utiliser d'alias, mais en configurant un virtualhost. Je n'arrive pas à le faire.  
+est il possible de m'aider merci

content/comments/configurer-reverse-proxy-apache/11.md

@@ -0,0 +1,8 @@
+email:
+date: 2011-10-21T13:54+01:00
+author: lexal
+website:
+
+Oh t'es encore vivant !!
+
+Toujours pratique quand t'as plusieurs NDD.

content/comments/configurer-reverse-proxy-apache/12.md

@@ -0,0 +1,10 @@
+email: cedric.blairon@periphelie.eu
+date: 2013-05-23T15:16+01:00
+author: Cedric BLAIRON
+website:
+
+Merci beaucoup pour cette explication simple et humoristique ;)  
+Nous utilisons dans la boite le reverse Proxy apache depuis maintenant presque 10 ans et c'est efficace et très performant.  
+Merci pour le rappel de quelques fonctionnalités.  
+
+Cédric

content/comments/configurer-reverse-proxy-apache/13.md

@@ -0,0 +1,10 @@
+email: olivier@olivier-raulin.fr
+date: 2013-08-28T14:58+01:00
+author: Olivier Raulin
+website: http://www.olivier-raulin.fr
+
+Oh, article très intéressant, qui vient de me faire réaliser que je pouvais faire ça pour joindre différentes machines sans passer par des ports exotiques chez moi !
+
+C'est ... super cool :-)
+
+Je vais tenter de le faire avec nginx, histoire que ce soit plus léger ... j'en ferai sûrement un petit article sur mon blog (je penserai à toi, ne t'en fais pas :) )

content/comments/configurer-reverse-proxy-apache/14.md

@@ -0,0 +1,10 @@
+email: courriel@victor-hery.com
+date: 2013-08-28T15:01+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 13md
+
+Merci pour le compliment :)  
+C'est sûr que ça permet d'éviter pas mal de manipulation pas très simple avec des ports exotiques ^^  
+Par contre, je ne suis pas pleinement satisfait des possibilités avec HTTPS (que la connexions soit chiffrée uniquement jusqu'au proxy, et plus ensuite..), mais pas trouvé mieux pour l'instant.  
+Si jamais tu as des idées, n'hésite pas à me faire signe ;)

content/comments/configurer-reverse-proxy-apache/15.md

@@ -0,0 +1,9 @@
+email: olivier@olivier-raulin.fr
+date: 2013-08-28T19:29+01:00
+author: Olivier
+website: http://www.olivier-raulin.fr
+replyto: 13md
+
+Comme promis, j'ai donc fait la même configuration pour nginx, pour ceux que ça peut intéresser : http://blog.olivier-raulin.fr/2013/08/28/mise-en-place-dun-reverse-proxy-nginx/
+
+J'imagine que tu as essayé dans le ProxyPassReverse de mettre https://ip/, ça ne fonctionnait pas ?

content/comments/configurer-reverse-proxy-apache/16.md

@@ -0,0 +1,10 @@
+email: courriel@victor-hery.com
+date: 2013-08-29T14:28+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 13md
+
+Oui, c'est le premier truc que j'avais essayé, mais ça ne fonctionnait pas, de mémoire à cause du fait que l'IP dans le certificat ne correspondait pas à la cible, quelque chose dans ce gout là.  
+Bon, j'y ai pas passé des jours non plus (disons des minutes :) )
+
+Merci pour la covnersion en NginX en tout cas, ça me donnera peut être l'occasion que j'attendais de découvrir ce serveur web ^^

content/comments/configurer-reverse-proxy-apache/17.md

@@ -0,0 +1,14 @@
+email: daumas.frederic@free.fr
+date: 2014-01-03T20:47+01:00
+author: Frederic
+website:
+
+bon tuto. Concernant ton problème de https pour que cela fonctionne, le reverse proxy doit définir dans le header X-Forwarded-Proto si la requête était en http ou https
+
+Par exemple la régle de récriture apache pour forcer l’https doit être :
+
+    RewriteEngine On
+    RewriteCond %{HTTP:X-Forwarded-Proto} !https
+    RewriteRule / https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
+
+Bye !

content/comments/configurer-reverse-proxy-apache/18.md

@@ -0,0 +1,16 @@
+email:
+date: 2014-01-06T13:46+01:00
+author: vignemail1
+website:
+
+L'idéal serait de passer par deux reverse proxies qui sont redondant l'un avec l'autre.   
+Pour cela il faut 4 adresses IP : 1 par serveur, 2 VIP (IP virtuelles) qui sont réparties sur les deux serveurs.  
+Ensuite, on met au niveau DNS que les deux VIP sont les adresses d'accès aux services.   
+Si l'un des serveurs tombe, sa VIP rejoint celle sur l'autre serveur et ainsi rend le service sans (quasiment) coupure.  
+De même, il est idéal de redonner de la même manière les backend HTTP afin de pouvoir procéder à des maintenances.  
+
+Parmi les avantages du reverse proxy :  
+  - si tu changes de serveur interne, c'est transparent pour les clients car tu n'as pas de délai de propagation DNS à gérer, tu restes avec le même couple FQDN/IP, tu changes juste les directives ProxyPass et ProxyPassReverse.  
+  - si ton site est piraté et qu'un script bot est installé pour donner un accès shell, il te suffit de retirer la route par défaut du backend HTTP et les accès initiés par le site piraté ne pourront s'établir car il n'y a pas de route par défaut.
+
+A noter pour le tuto : le vhost du serveur interne doit être le même que ce sur quoi le reverse proxy répond dû à la directive ProxyPreserveHost

content/comments/configurer-reverse-proxy-apache/19.md

@@ -0,0 +1,10 @@
+email: courriel@victor-hery.com
+date: 2014-01-12T21:27+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 18md
+
+Je suis d'accord c'est le genre d'infra idéale, mais là pour le coup, juste pour héberger le blog ça consomme un peu trop de ressources !
+C'est clair que les VIP permettent de régler plutôt facilement tout ce qui est problématique DNS pour qui veut de la haute disponibilité.
+
+Merci pour les com :)

content/comments/configurer-reverse-proxy-apache/2.md

@@ -0,0 +1,30 @@
+email: mtg63@hotmail.com
+date: 2015-03-17T21:41+01:00
+author: Rémi
+website:
+
+Merci pour ce tuto très bien documenté.  
+Je bloque sur un soucis et je n'arrive pas à mettre le doigt sur le problème.  
+Derrière une box (port 80 redirigé), j'ai un ordi fix + un raspberry pi. Chacun fait office de serveur web (apache). Le reverse proxy est activé sur le fix. Les domaines sont noip1 et noip2 pointant sur l'ip de ma box.
+
+/etc/apache2/sites-available/monsite1 (j'ai utilisé Defaut comme base et que j'ai configuré comme indiqué dans le tuto). De ce côté là toout est ok.
+
+/etc/apache2/sites-available/monsite2 (celui pointant sur le pi) :
+    < VirtualHost *:80 >
+            ServerName noip.zapto.org
+            ProxyPreserveHost On
+            ProxyRequests Off
+            ProxyPass / http://192.168.1.10/v
+            ProxyPassReverse / http://192.168.1.10/
+    < /VirtualHost >
+Cela fonctionne en local, mais pas à partir du Net.
+Ais-je omis quelque chose ?
+
+Lorsque je reload ou restart apache, j'ai comme retour :
+    [....] Reloading web server config: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
+    [Tue Mar 17 21:31:35 2015] [warn] NameVirtualHost *:80 has no VirtualHosts
+    . ok
+
+Je ne pige pas d'où vient le problème, y a t-il relations avec le fichier /etc/hosts ou un soucis dhcp avec /etc/network/interfaces ?
+
+Merci d'avance

content/comments/configurer-reverse-proxy-apache/20.md

@@ -0,0 +1,28 @@
+email: neh.mobile@gmail.com
+date: 2014-01-21T23:20+01:00
+author: Blotto
+website:
+
+Slt
+
+@Victor et pour les autres qui ont galeré comme moi !!!
+
+Le problème provient du proxy qui ne peut pas valider un certificat autosigné, il faut lui indiquer manuellement l'emplacement du certificat pour qu'il puisse effectuer la connexion.
+
+Modèle :
+
+client---https---proxy---https---serveur
+
+Copie le certificat SSL du serveur sur le Proxy via SCP et ensuite ajoute ceci a ton virtualhost.
+
+    SSLProxyEngine On
+    # Pointe le certificat directement
+    SSLProxyCACertificateFile /etc/apache2/ssl/serveur.crt
+
+ou
+
+    SSLProxyEngine On
+    # Pointe le dossier du certificat
+    SSLProxyCACertificatePath /etc/apache2/ssl/
+
+Marche impec sur Proxmox 3.1

content/comments/configurer-reverse-proxy-apache/3.md

@@ -0,0 +1,8 @@
+email: cleblanc95@gmail.com
+date: 2015-04-28T20:33+01:00
+author: Cyril
+website: http://cyril-leblanc.fr
+
+Bonjour,  
+Si je souhaite que quick.com soit un proxy de nddhidden.com. Et donc que quand je tappe http://quick.com/007-article-numero-un redirige sans que l'utilisateur au bout le sache vert   http://nddhidden.com/007-article-numero-un  
+Est-ce que cela fonctionnera ?  

content/comments/configurer-reverse-proxy-apache/4.md

@@ -0,0 +1,10 @@
+email: jerem-rider@hotmail.fr
+date: 2015-05-26T16:59+01:00
+author: jeremy
+website:
+
+bonjour
+
+Merci pour ce tuto
+
+Comment gérer pour que le  proxy mette en cache les pages afin de soulager le serveur web

content/comments/configurer-reverse-proxy-apache/5.md

@@ -0,0 +1,13 @@
+email: fbms18@hotmail.com
+date: 2015-06-19T15:47+01:00
+author: Fred
+website:
+
+Bonjour,
+
+Merci pour ce tuto.
+Je suis un peu en galère avec mon reverse proxy, il fonctionne mais j'ai des problèmes d'encodage. Quand je charge ma page, les accents sont transformés, et ca passe de "é" à "é" par exemple. mais si je force à recharger la page sur mon navigateur (ctrl+R) les accents s'affichent correctement.
+
+Y a t'il une config particulière pour ne pas avoir de problèmes d'accents ?
+
+Encore merci

content/comments/configurer-reverse-proxy-apache/7.md

@@ -0,0 +1,15 @@
+email: jmcafagna@hotmail.com
+date: 2015-10-01T09:06+01:00
+author: Jean-Michel
+website:
+
+Si tu es toujours intéressé pour avoir une connexion HTTPS avec tes serveurs interne depuis ton reverse proxy
+
+Rajoute dans la définition de ton virtualhost sur ton reverse proxy, ceci:
+
+    SSLProxyCheckPeerCN	off
+    SSLProxyCheckPeerName	off
+
+ces deux instructions permettent d'utiliser un certificat auto-signé sur le serveur interne.
+
+c'est peut être pas très joli mais ça fonctionne.

content/comments/configurer-reverse-proxy-apache/8.md

@@ -0,0 +1,6 @@
+email: d.marguerat@multiarts.ch
+date: 2015-02-21T11:56+01:00
+author: Doms
+website:
+
+Merci, vous m'avez sorti d'une impasse. Bravo.

content/comments/configurer-reverse-proxy-apache/9.md

@@ -0,0 +1,9 @@
+email: contact@web2diz.net
+date: 2015-03-05T17:38+01:00
+author: Manu
+website:
+
+Merci pour ces explication c'est maintenant bien plus clairt ! J'ai pu faire moi aussi mon authentification sécurise et crypté avec ssl (SHA2) / reverse proxy et certificat client (ou mot de passe) ... Le tout tourne très bien depuis plusieurs semaines sur mon raspberry...
+Si vous souhaitez des détails j'ai moi aussi fait un tutoriel : http://domoticz.web2diz.net/?p=493 je me suis permit de faire référence à cette page.
+
+Merci encore et A+

content/comments/dns-dynamique-ovh-avec-wrt54gl/0.md

@@ -0,0 +1,6 @@
+email:
+date: 2013-10-05T13:49+01:00
+author: blue
+website:
+
+Un grand merci, cela m'évite de trop chercher cette URL "custom" pôur OVH sur ce magique WRT54GS & Tomato :)

content/comments/dns-dynamique-ovh-avec-wrt54gl/1.md

@@ -0,0 +1,6 @@
+email: mouitido@hotmail.com
+date: 2014-07-17T16:51+01:00
+author: mouitido
+website:
+
+j'ai testé, mais dans mon ça ne marche pas, le procédure est-elle la même depuis se temps....

content/comments/dns-dynamique-ovh-avec-wrt54gl/2.md

@@ -0,0 +1,9 @@
+email: courriel@victor-hery.com
+date: 2014-07-17T17:45+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 1md
+
+Bonjour mouitido,
+A ma connaissance, les wrt où je l'avais configuré fonctionnent toujours, mais avec les modifications du manager OVH qui s'enchainent, il est possible que l'api ait un peu changée.
+Est ce que tu as bien configuré l'utilisateur et le mot de passe dans l'URL sur le wrt, et que tu as bien autorisé la modification en dynamic DNS dans l'interface OVH ?

content/comments/marre-filtrage-securite-hebergeurs/0.md

@@ -0,0 +1,8 @@
+email:
+date: 2012-09-08T13:33+01:00
+author: lexal
+website:
+
+C'est sur on est jamais aussi bien hébergé que par soit même, vivement la fibre optique pour tous ^^.
+
+Après je pense que moyennant finance on peut toujours avoir plus de liberté sur un hébergement mais c'est sur la ça devient vraiment hors de prix

content/comments/marre-filtrage-securite-hebergeurs/1.md

@@ -0,0 +1,12 @@
+email:
+date: 2012-09-08T17:23+01:00
+author: Cedric
+website:
+
+[Mode Troll]
+L'auto hébergement c'est bien, mais tout le monde n'a pas trois fibres optiques géographiquement répartie avec la clim à tout les étages et des vitres parballes à l'accueil et un groupe électrogène dans la cave :-)
+
+Ok pas trés utile tout ca pour un blog.
+
+L’auto-hébergement c'est bien, si tu peux te passer de ton hébergement !
+[/Mode Troll]

content/comments/marre-filtrage-securite-hebergeurs/2.md

@@ -0,0 +1,8 @@
+email: courriel@victor-hery.com
+date: 2012-09-08T20:26+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 1md
+
+C'est vrai que j'aurai pu préciser, si tu as besoin d'un hébergement industriel, là ça le fait plus :)
+M'enfin, il fallait bien une morale de fin ^^

content/comments/marre-filtrage-securite-hebergeurs/3.md

@@ -0,0 +1,7 @@
+email: bloguebinome@thibaud.info
+date: 2012-09-08T17:23+01:00
+author: Thibaud
+website:
+
+Des noms! Des noms! Des noms! OVH? Online? ^^
+En tout cas, je compatis largement. Ne pas faire confiance à ses propres adresses IP mais à celles de tous les autres FAI de la planète... c'est comique. ^^

content/comments/marre-filtrage-securite-hebergeurs/4.md

@@ -0,0 +1,7 @@
+email: courriel@victor-hery.com
+date: 2012-09-11T11:21+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 3md
+
+Non, pas de nom, ce n'est pas une attaque personnelle ! Ceci dit, il y a des indices pour trouver la réponse à cette question :)

content/comments/marre-filtrage-securite-hebergeurs/5.md

@@ -0,0 +1,8 @@
+email: lecorvaisier.jerome@gmail.com
+date: 2013-02-10T05:28+01:00
+author: Jérôme
+website:
+
+Ouhhhh par expérience OVH le fait... Mais j'ai été plus rapide que toi pour trouver... En revanche... j'étais aussi plus con puisque ne comprenant pas... J'ai réinstallé le serveur dédié =)
+
+Oui... c'était un serveur de test :)

content/comments/marre-filtrage-securite-hebergeurs/6.md

@@ -0,0 +1,10 @@
+email: lecorvaisier.jerome@gmail.com
+date: 2013-02-10T05:35+01:00
+author: Jérôme
+website:
+
+En ce qui concerne l'auto hébergement, il y a plusieurs problèmes, déjà le cout de l'hébergement en lui même, est multiplié par approximativement 2 sur 1 an, un OVH en bas de gamme coute au bas mot 200€, c'est à peu près le prix d'un NAS (bah oui il faut bien une machine supplémentaire, comme si on prenait un OVH supplémentaire) mais sans disque ou alors je ne sais pas de quel camion sort votre NAS :)
+
+Tout ça c'est bien... Mais il y a aussi une histoire d'électricité sans compter le temps à s'occuper de la partie matérielle qui est gérée par l'hébergeur de manière quasi instantanée...
+
+L'auto hébergement c'est le bien, mais qu'a Orange comme intérêts à te poser une grosse fibre pour que tu n'utilises plus ses services de pages persos mais ton propre serveur, mise à part qu'ils vont dépenser une fortune ? :)

content/comments/marre-filtrage-securite-hebergeurs/7.md

@@ -0,0 +1,21 @@
+email: courriel@victor-hery.com
+date: 2013-02-10T12:48+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 6md
+
+Hello,
+
+Pour ma part, j'aime bien l'auto-hébergement pour son principe. Il est vrai que la bade passante est un vrai problème, et du coup ça reste de l'hébergement non-industriel. Le jour où ce blog attirera vraiment les foules, je repenserai sans doute à mon schéma d'utilisation, mais je n'y suis pas encore ! Et un peu de QOS peut régler bien des choses :)
+
+Niveau coûts de la machine et electricité, c'est plus difficile à calculer, car si en effet un hébergement bas de gamme chez OVH ne coute pas grand chose, ça reste un paiement au mois. Acheter un serveur, c'est un cout fixe. Pour ma part, mon serveur perso m'a couté moins de 200€, il est très largement évolutif, et il consomme très peu.
+Il ne fait également aucun bruit :)
+Je t'invite à jeter un coup d'oeil aux articles du développeur neurasthénique sur ce sujet, il sont plutôt intéressants :
+http://blog.developpeur-neurasthenique.fr/auto-hebergement-composants-pour-une-nobox-libre-et-acentree.html
+http://blog.developpeur-neurasthenique.fr/auto-hebergement-un-an-apres-petit-bilan-avant-le-debut-des-hostilites.html
+
+Pour ma part, j'avoue que je n'ai pas encore eu le courage de faire un article sur ma nobox perso. Je suis plutôt parti sur une solution sous forme de tour, un peu plus encombrante mais plus évolutive. Ca permet également d'avoir du matériel un peu plus puissant avec des ventilateur faisant moins de bruit. Et l'énorme avantage de Proxmox c'est qu'avec un bon backup, il est facile de basculer ailleurs si jamais un problème se pose :)
+(Bon, il faut avoir prévu le coup...)
+Typiquement, mes tutos sur un cluster Proxmox ne se pose pas vraiment dans une problématique d'auto-hébergement, mais plutôt dans une idée de services à haute disponibilité ! ;)
+Tout est une question d'énergie et de temps à y passer.
+L'auto-hébergement permet quand même de bien s'amuser, sur des points qui serait impossible en hébergé (notamment la QOS)

content/comments/virtualisation-bienfait-du-cloud/0.md

@@ -0,0 +1,6 @@
+email: caubert@kicou.org
+date: 2012-08-16T22:18+01:00
+author: Cedric
+website: http://blogvps.kicou.org
+
+Houas comment ca donne trop envie de se mettre un proxmox dans son garage :-)

content/comments/virtualisation-bienfait-du-cloud/1.md

@@ -0,0 +1,7 @@
+email:
+date: 2012-08-21T12:20+01:00
+author: lexal
+website:
+Très bon article
+
+Par contre dans certains types de virtualisation (Para Virtualisation) sur lesquels le systèmes d'exploitation invité est conscient d'être virtualisé afin d'optimiser la virtualisation.

content/comments/virtualisation-bienfait-du-cloud/2.md

@@ -0,0 +1,8 @@
+email: courriel@victor-hery.com
+date: 2012-08-21T20:40+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 1md
+
+Ah, je n'avais pas entendu parler de ce genre de virtualisation. Je vais me renseigner et modifier l'article alors :)
+(J'ai du mal à situer en quoi ça optimise la virtualisation d'ailleurs, à creuser)

content/comments/virtualisation-bienfait-du-cloud/3.md

@@ -0,0 +1,7 @@
+email:
+date: 2012-08-22T13:46+01:00
+author: lexal
+website:
+replyto: 1md
+
+C'était utile quand la virtualisation était moins performant. La para virtualisation permettait que le systèmes invité adapte ses requêtes car il sait que les ressources sont partagées. Mais c'est sur que maintenant je vois pas trop la différence a part à très grande échelle comme Amazon ou autre

content/comments/virtualisation-opensource-qui-roxx-proxmox/0.md

@@ -0,0 +1,6 @@
+email:
+date: 2012-09-05T11:32+01:00
+author: lexal
+website:
+
+Ca m'a l'air pas mal tout ca faudra que je test un jour ^^

content/comments/virtualisation-opensource-qui-roxx-proxmox/1.md

@@ -0,0 +1,6 @@
+email: Denise47@laposte.net
+date: 2012-10-15T21:48+01:00
+author: mahjong
+website:
+
+Hello, bravo pour votre bel article ! J'attend avec impatience la suite. Amicalement, Denise

content/comments/virtualisation-opensource-qui-roxx-proxmox/2.md

@@ -0,0 +1,11 @@
+email: courriel@victor-hery.com
+date: 2012-10-16T23:06+01:00
+author: Victor
+website: http://blog.xn--hry-bma.com/
+replyto: 1md
+
+Hello,  
+Merci pour ces encouragements :)  
+Je prépare actuellement 2 gros articles (mais ça sera peut être plutôt 4 au final) sur monter un cluster proxmox entre plusieurs data center différents, à coup d'OpenVPN.  
+Avec un ajout également sur comment faire fonctionner tout ça en haute disponibilité.  
+C'est un assez gros projet, donc ça va lentement, mais on va arriver au bout ! ;)

content/comments/virtualisation-opensource-qui-roxx-proxmox/3.md

@@ -0,0 +1,9 @@
+email: gael46007@gmail.com
+date: 2014-05-14T17:11+01:00
+author: Garcia
+website: http://rjm-aviation.net/
+
+C'est excellent, trop bon, trop fort, trop puissant.  
+J'ai virtualisé 5 windows + un srv 2010 + 2 debian pour faire srv web la machine chez OVH est à 15 % de sa puissance...  
+Le tout sur un srv Canadien... Trop puissant la realease OVH  
+A addpter