Version pour les serveurs installés en 2014, basé sur l'architecture déjà en place.
L'objectif de ce guide et de formuler de manière la plus détaillée possible la mise en œuvre de ma nouvelle architecture serveur. Ce guide s'inspire de nombreux autres guides qui seront repris en grande partie. L'idée est de disposer d'un manuel autonome qui pourra persister y compris après la disparition des sites de références.
Cette partie liste tous les liens qui m'ont servi à construire ce guide. C'est à ordonner mieux que ça mais le vrac a le mérite de lister les choses.
Nombre d'étapes de ce guilde sont communes aux deux serveurs physiques. Il s'agit de les dérouler et d'apporter quelques personnalisations selon les cas.
A noter que nous aurons deux serveurs physiques nommés ainsi (pour l'exemple mais a adapter selon votre config) :
Note importante : que chacune des opérations abordées dans les sous chapitres de cette partie sont à faire sur chacun des serveurs physiques en adaptant bien sur la configuration lorsque c'est nécessaire.
Comme depuis un moment maintenant, je suis chez online.net. J'ai donc choisi assez naturellement leurs petits serveurs dédiés, soit 2 LT 2014 de la gamme start LTS.
Je voulais une distribution qui facilite la construction de cluster et permette la virtualisation. L'idée est de pouvoir monter plusieurs serveurs virtuels avec seulement deux machines physiques et pouvoir migrer les VM facilement d'un noeud à l'autre en cas de crash.
La distribution que j'ai choisie sera donc proxmox. Elle permet la virtualisation et a le mérite d'être un minimum ouverte (bien que cela change un peu ces temps derniers), d'être gratuite si l'on ne prend pas de support et de fonctionner de manière assez simple avec des outils linux connus mais packagés correctement. Je ne dis pas que ESXI est mauvais, mais juste que dès qu'il s'agit de bidouiller et ajouter de fonctionns ce n'est pas possible sur ESXI (sauf a sortir son carnet de chèques).
Pour cette architecture, nous allons fonctionner sur un cluster avec 2 noeuds. En théorie, un cluster permettant de faire du HA doit comporter un nombre impaire de noeuds donc au moins 3 (notamment pour des histoires de quorum). Je n'ai pas choisi de partir sur cette architecture pour plusieurs raisons :
Nous partons donc sur 2 noeuds, un principal et un secondaire. L'idée est que sur ce cluster les VM puissent migrer très facilement d'un noeud à l'autre en cas de défaillance d'un des noeuds.
Comme je le disais, je souhaite mettre en place une solution me permettant une architecture robuste et tolérante aux pannes. Ce qui veut dire pouvoir démarrer mes VM sur n'importe quel noeud et ce même après le crash d'un noeud. Il existe pas mal de choses pour faire cela mais j'ai choisi de mettre en place une architecture basée sur DRBD.
DRBD me permet ainsi de mettre en place une réplication bidirectionnelle entre des disques de mes deux clusters. Ansi, toute l'activité d'un cluster est répliquée en temps réel sur l'autre serveur ce qui, en cas de crash me permet de démarrer sans perte la VM sur le noeud restant grâce aux données répliquées.
Attention, pour éviter les problèmes (comme moi lors de ma première tentative), vous devez mettre en place 2 disques en réplication bidirectionnelle sur chaque noeud du cluster. Pourquoi ? Parce que si vous faites tourner en même temps les VM de chaque cluster sur le même disque DRBD (avec répli bidirectionnelle) vous aurez fatalement du split brain. Ce qui est assez dur à régler. En gros en cas de crash vous aurez le même disque DRBD (normalement synchro sur les deux noeuds du cluster) qui aura vécu sa vie de manière différente sur chacun des noeuds. Les données sont donc à resynchro des deux côtés et vous ne pouvez pas écraser un le disque DRBD d'un noeud avec celui de l'autre “plus récent” puisqu'il y a des données différentes des deux côtés. Dans ce cas (vécu chez moi) vous pourriez être obligés de perdre des données…
La manière simple d'éviter cela est donc d'avoir deux disques DRBD sur chaque noeud du cluster. Pour chaque noeud, n'utiliser qu'un seul disque DRBD différent de l'autre noeud pour faire tourner les VM. Ansi en cas de crash vous pourrez facilement restaurer les données d'un disque périmé avec celles de celui qui a tourné sans risquer de perdre des données.
Je me base pas mal sur cet article de Victor Héry ainsi que mes expériences perso sur la précédente configuration, qui m'ont amenées à vouloir tester d'autres façons de faire.
Chaque serveur de cette gamme dispose de deux cartes réseau physique :
Par défaut votre configuration proxmox aura une interface bridgée vmbr0 connectée à l'interface physique qui sera sur le réseau public.
Pour notre architecture nous mettrons en place un autre bridge pour les VM : vmbr1. Nous détaillerons la configuration plus bas. Ce bridge assurera pour la communication entre les VM ainsi que la réplication DRBD. Les deux machines physiques seront mises en relation via ces bridges et un tunnel VPN.
On utilisera le réseau RPN pour les opérations cluster proxmox. Par défaut il faut du multicast, mais on sait le désactiver pour fonctionner en unicast. L'idée ici est de ne pas tout mettre sur le VPN et donc utiliser un peu le RPN pour les échanges interne proxmox. De plus cela augmente la fiabilité : pas tous les œufs dans le même panier. Par contre il faut noter que par défaut le réseau RPN est à une vitesse de 100Mbps ce qui est insuffisant pour une réplication DRBD : raison de plus pour la faire sur OpenVPN qui sera configuré via les interfaces publiques du serveur qui elles fonctionnent à 1Gpbs.
Note : avoir le RPN à 100Mbps est possible mais c'est une option qui va vous obliger a prendre un niveau de service online.net supérieur à “Basic” (qui lui est gratuit). Là en gros vous allez devoir sortir au minimum 20 euros HT en plus par serveur pour avoir ce niveau de service. Ensuite il faudra encore rajouter quelques euros pour avoir l'option RPN 1Gbps. BREF ! Quand on est pas super riche on ruse avec le VPN sur l'interface publique. Si on est riche alors je vous encourage a utiliser le RPN au maximum car cela évitera de charger les interfaces publiques par lesquelle tout le traffic internet arrive déjà. De plus niveau robustesse c'est mieux. Si l'interface publique est down, le réseau RPN est toujours potentiellement OK lui… Bref, la solution VPN est un compromis économique mais qui comporte des défauts de conception…
Les premières étapes sont assez simple chez online, après un tour sur l'interface d'admin, on choisit sa distribution et on lance l'installation pour chacun des serveurs.
On retouchera plus tard les choses qui ne vont pas comme par exemple le partitionnement. De toutes manières, l'outil de partitionnement ne permet pas grand chose sur l'interface online.net. Si on demande une configuration vraiment spécifique, l'outil ne fonctionne pas et n'enregistre rien du tout.
Note : vous vous dites que vous pourriez faire une installation manuelle via Idrac pour résoudre les limitations de l'install web. C'est pas faux. Sauf que pour activer l'idrac (ou l'ilo si vous avez un serveur hp) il faut de toutes façons installer complètement le serveur au moins une fois avec que l'option idrac ou ilo aparaisse sur l'interface d'admin de votre dédié… Bref, ça n'évite pas une première install bateau via le web quoi qu'il arrive…
Si vous n'utilisez comme moi que la version gratuite, il faut désactiver les mises à jour venant de la version pro en commantant le deb dans ce fichier :
nano /etc/apt/sources.list.d/pve-enterprise.list
Puis ensuite lancer la mise à jour.
apt-get update apt-get upgrade
En grande partie repris (aux perso près) de cet article..
Afin de rendre le shell plus lisible avec quelques couleurs dont celle du prompt qui pourra être différente selon le noeud du cluster.
nano /etc/bash.bashrc
Et on ajoute cela à la fin du fichier :
# # Colors and prompt configuration # C_RED="[e[1;31m\]" C_BLUE="[e[1;34m\]" C_GRAY="[e[1;30m\]" C_WHITE="[e[1;37m\]" C_YELLOW="[e[1;33m\]" C_DEF="[033[0m\]" mUID=`id -u` MACHINE=`hostname -f` #if [ "$mUID" = "0" ] ; then PS1="${C_RED}\u${C_DEF}@${C_RED}${MACHINE}${C_DEF}:\w${C_RED}#${C_DEF} " PS2="${C_RED}>${C_DEF} " #else #PS1="${C_BLUE}\u${C_DEF}@${MACHINE}:\w${C_BLUE}\$ ${C_DEF}" #PS2="${C_BLUE}>${C_DEF} " #fi export PS2 export PS1 case $TERM in xterm*) PROMPT_COMMAND='echo -ne "\033]0;${USER}@${MACHINE}: ${PWD}\007"' echo -ne "\033]0;${USER}@${MACHINE}: ${PWD}\007" ;; *) setterm -blength 0 ;; esac # # Alias configuration # alias l='ls -ahlF --color=yes --full-time --time-style=long-iso | more' alias ll='ls -alhF --color=yes --full-time --time-style=long-iso' alias cpav='cp -av'
Note : pour activer un prompt différent entre root et les autres users, vous n'avez qu'a décommenter le if.
A noter également que les autres users que root ont un .bashrc dans leur réportoire home très complet écrasant la configuration qu'on vient de faire. Donc deux options, soit on personnalise aussi le .bahsrc de tous les users soit on le simplifie pour que le paramétrage par défaut s'applique. Pour ma part je choisis l'option 2 en recopiant le .bashrc minimaliste du user root.
Donc dans le répertoire home du user (ex : /home/monuser)
cp /root/.bashrc .
Et on oublie pas de vérifier que les droits sont bien pour le user courant sur ce fichier, sinon changer user / group avec chown.
Pour le second serveur, on renouvelle l'opération de manière identique.
Je conseille de changer les couleurs du prompt avec autre chose pour bien différentier les serveurs. Pour cela dans les lignes “PS1=” changer C_RED par la couleur de votre choix.
Il est très utile (par exemple pour les mails) d'avoir une zone DNS correctement configurée pour accéder à ses serveurs. Cela veut dire au minimum, que vous allez vous acheter un nom de domaine et configurer ensuite des sous domaines pour vos différentes machines.
Evidemment les parties type machine1.domaine.net sont à personnaliser tout comme IP_SERVEUR_PHYSIQUE_1.
Exemple :
Avec une conf DNS de ce genre par machine :
Et une conf SPF de ce genre pour ne pas vous faire jeter par les analyses antispam (toujours pour chaque serveur) :
Et bien sur ne pas oublier de modifier les reverses de vos serveurs pour qu'ils pointes sur les domaines que vous venez de définir. Pour online.net il suffit d'aller sur la console d'administration de votre serveur et cliquer sur “Modifier les reverses” et vous mettez le domaine correspondant (ex : machine1.domaine.net.).
*Note importante :* attention la propagation des DNS peut mettre un certain temps. Disons jusqu'à 24 à 48H pour être à jour partout. Donc il vaut mieux anticiper cette partie… Cela dit pour ce qu'on a à faire la mise à jour va assez vite (quelques minutes tout au plus).
Il faut maintenant changer le nom des machines, conformément à ce qu'on a mis en DNS et en reverse. C'est un peu particulier sur proxmox et j'ai trouvé ce topic qui en parle pas mal. Comme toujours, à adapter en fonction de votre config.
Changer le fichier hostname :
nano /etc/hostname
machine1
Puis le fichier hosts :
nano /etc/hosts
# Localhost 127.0.0.1 localhost IP_SERVEUR_PHYSIQUE_1 machine1
Evidemment il peut y avoir d'autres choses sur la ligne de IP_SERVEUR_PHYSIQUE_1.
Note 1 : nous verrons tout à leur que nous rechangeront cette configuration pour l'adapter aux besoins du cluster et des VM mais pour l'instant faisons propre :)
Et enfin changement du certificat proxmox (faites un ptit backup au cas ou avant et regardez aussi ce topic) :
rm /etc/pve/pve-root-ca.pem
pvecm updatecerts --force
Note 2 : mieux vaut faire cette opération de suite, car ce sera le bordel une fois le cluster monté… Changer le nom des machines en cours de route alors qu'elles sont utilisées pour identifier les noeuds, ça sent le sapin !
Par défaut la configuration de postfix laisse à désirer. Il faut donc y redonner un coup de tournevis :
dpkg-reconfigure postfix
La conf que j'utilise (réponse aux écrans 1 par 1) :
Et un petit tour dans le fichier de conf postfix (précédemment édité) pour vérifier que tout est OK et modififier myhostname, mydomain avec par exemple machine1.domaine.net et enfin /etc/postfix/generic pour forcer la réécriture des “from”.
nano /etc/postfix/main.cf
Ce qui vous donnera
myhostname = machine1.domaine.net mydomain = mondomaine.net smtp_generic_maps = hash:/etc/postfix/generic
On crée / modifie le fichier generic :
nano /etc/postfix/generic
Qui ressemble à ceci (voir la documentation postfix) :
@machine1 noreply@machine1.mondomaine.net
On active la configuration contenu dans le fichier generic et on reboot postfix :
postmap /etc/postfix/generic service postfix restart
Note 1 : Pour la debian fournie avec promox 3 (squeeze je crois) pas besoin de configuration avec un fichier generic pour réécrire les adresses mail expéditeur. Il prend correctement myhostname. Par contre pour la dernière ubuntu (la trusty) impossible de lui faire prendre myhostname ou mydomain ou myorigin… Donc seule la configuration avec generic permet de forcer l'écriture d'une adresse expéditeur correcte.
Note 1.1 : Après enquête la différence (que je soupçonne) serait sur l'absence de procmail sur la dernière ubuntu contraitement à la debian…
Note 2 : Dans generic je force a une adresse norply@ pour éviter de montrer les users système qui envoient les mails dans les mails automatiques. A adapter a votre configuration.
Note 3 : C'est très important de bien configururer une bonne adresse from qui correspond à votre host.domaine.net car ça vous permettra d'éviter les échec (et donc refus ou spam) d'envoi de mail sur la négocation avec les serveurs distants via HELO (ce topic en parle pas mal).
Note 4 : Il est très très important d'avoir des dns configurés (host.domaine.net) correctement pour émettre vos mails. Car sinon tous les mails envoyés par votre serveur finiront dans la boite à spam (meilleur des cas) voire vos ip seront blacklistées. Pourquoi ? En gros parce que vos serveurs enverrons des mails avec des dns incohérents et les filtres antispam sont sans pitié !
Pour en savoir plus sur la configuration correcte de postfix pour éviter les spams, se référer à cet article, plus détaillé.
En grande partie repris de cet article. Je reprends quasi tel que (défois que ça disparaisse), sauf peut être la partie firewall que j'ai adaptée.
N'hésitez pas à modifier le mot de passe surtout si celui-ci vous a été attribué par défaut. Identifiez-vous d'abord en root (voir ci-dessus) puis entrez la commande :
passwd root
Afin de sécuriser l'accès SSH au serveur, éditons le fichier /etc/ssh/sshd_config. Nous allons changer le port de connexion par défaut pour éviter quelques attaques par bruteforce sur le port 22, qui est bien connu pour héberger ce service. N'oubliez pas de préciser ce nouveau port (dans Putty ou en ligne de commande ssh sous Linux) à la prochaine connexion.
nano /etc/ssh/sshd_config
Pour rappel, le port et le users sont à changer en fonction de votre configuration perso bien sûr.
Port 2222 # Changer le port par défaut (à retenir!) PermitRootLogin yes # Obligé a cause de proxmox
Dans l'idéal on devrait n'autoriser qu'un user a se connecter et surtout pas root :
PermitRootLogin no # Ne pas permettre de login en root AllowUsers dew # N'autoriser qu'un utilisateur précis
Mais on ne le fera pas hélas car proxmox a besoin de se connecter en root notamment pour les histoires de gestion du cluster.
Pour la partie client (et surtout pour proxmox) on doit également changer la configuration de base du client ssh pour qu'il utilise le port qu'on a changé (qui n'est plus le port par défaut) :
nano /etc/ssh/ssh_config
Et modifier la ligne du port pour l'adapter à votre configuration :
Port 2222
La modification est à faire sur les deux noeuds. Sans cette modification, lorsque vous voudrez ajouter votre 2eme noeud au cluster vous aurez un beau
unable to copy ssh ID
Redémarrez le service SSH après ces modifications :
service ssh restart
Vous pouvez éditer le fichier /root/.bashrc (ou celui d'un utilisateur lambda /home/myuser/.bashrc) qui est exécuté au démarrage d'une sesion root (ou du user correspondant) pour envoyer un e-mail de notification. De cette façon, vous serez prévenu lorsqu'un login est effectué.
nano /root/.bashrc
Ajoutez la ligne (en modifiant l'adresse e-mail de destination) :
# # Mail alert on root connection # echo "Accès shell root le `date` `who`" | mail -s "`hostname` - Shell root de `who | cut -d"(" -f2 | cut -d")" -f1`" monitoring@test.com
Bon c'est un peu long et tout ne va pas servir de suite… Cependant il faut bien en parler à un moment ou un autre…
Pour désactiver l'IPv6, si vous n'en avez pas besoin (pas de troll :)) et ça évitera de devoir faire de la conf ipv6… (oui je suis flemmard mais ca n'est pas très utile pour moi a priori).
echo "options ipv6 disable=1" > /etc/modprobe.d/disable-ipv6.conf
On crée notre fichier de configuration
nano /etc/init.d/iptables
Et on le valorise dans ce gout là. A adapter en fonction de votre config et à faire pour chaque serveur physique. Bien sur quand on autorise le serveur 2 sur le serveur 1, on autorise le serveur 1 sur le serveur 2 (faut inverser).
Attention celui ci est très complet mais il faudra élaguer sans doute en fonction de vos besoins. Un principe de sécurité : on interdit tout et on ouvre que le stricte minimum.
Note : la configuration ftp passive est un peu délicate. Je me facilite donc la vie en ne l'utilisant que pour mon backup online en mode semi bourrin (voir cet article). Par ailleurs pour savoir si l'adresse est bien dedibackup-dc2.online.net Rendez vous dans la rubrique sauvegarde sur la page de votre serveur sur le site online.net.
#!/bin/bash echo Setting iptables / firewall rules... # # Dedibox iptables / firewall configuration # # http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot # http://wiki.debian.org/LSBInitScripts # http://documentation.online.net/fr/serveur-dedie/tutoriel/iptables-netfilter-configuration-firewall # http://www.alsacreations.com/tuto/lire/622-Securite-firewall-iptables.html # # Modifications alban.montaigu # ###### Start Initialisation ###### # Empty current tables iptables -t filter -F iptables -t filter -X echo - Empty current tables : [OK] # No input connection iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP echo - No input connection : [OK] # No output connection iptables -t filter -P OUTPUT DROP echo - No output connection : [OK] # Authorize private hosts for all # Physical public IP of physical server 2 iptables -A INPUT -s IP_SERVEUR_PHYSIQUE_2 -j ACCEPT iptables -A FORWARD -s IP_SERVEUR_PHYSIQUE_2 -j ACCEPT iptables -A OUTPUT -d IP_SERVEUR_PHYSIQUE_2 -j ACCEPT # Physical RPN IP of physical server 2 iptables -A INPUT -s RPN_IP_SERVEUR_PHYSIQUE_2 -j ACCEPT iptables -A FORWARD -s RPN_IP_SERVEUR_PHYSIQUE_2 -j ACCEPT iptables -A OUTPUT -d RPN_IP_SERVEUR_PHYSIQUE_2 -j ACCEPT # Authorize SSH iptables -t filter -A INPUT -p tcp --dport 2222 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 2222 -j ACCEPT echo - Authorize SSH : [OK] # Authorize OpenVPN interfaces (enable multicast) iptables -A INPUT -i tap+ -j ACCEPT iptables -A FORWARD -i tap+ -j ACCEPT iptables -A OUTPUT -o tap+ -j ACCEPT echo - Authorize OpenVPN : [OK] # Authorize interfaces on internal network (enable multicast) iptables -A INPUT -i vmbr1 -j ACCEPT iptables -A FORWARD -i vmbr1 -j ACCEPT iptables -A OUTPUT -o vmbr1 -j ACCEPT echo - Authorize vmbr1 [OK] # Do not break established connections iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT echo - Do not break established connections : [OK] ###### End Inialisation ###### ##### Start Rules ###### # Authorize DNS, FTP, HTTP, NTP iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT echo - Authorize DNS, FTP, HTTP, NTP : [OK] # Authorize loopback iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A OUTPUT -o lo -j ACCEPT echo - Authorize loopback : [OK] # Authorize ping iptables -t filter -A INPUT -p icmp -j ACCEPT iptables -t filter -A OUTPUT -p icmp -j ACCEPT echo - Authorize ping : [OK] # HTTP iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 8443 -j ACCEPT echo - Authorize HTTP : [OK] # Monit iptables -t filter -A INPUT -p tcp --dport 8080 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 8080 -j ACCEPT echo - Authorize monit : [OK] # Proxmox admin iptables -t filter -A INPUT -p tcp --dport 8006 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 8006 -j ACCEPT echo - Authorize proxmox admin : [OK] # Proxmox VNC it's ok because vncserver is started only when requested in the GUI iptables -t filter -A INPUT -p tcp --dport 5900 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 5900 -j ACCEPT echo - Authorize proxmox VNC : [OK] # FTP (passive dedibackup-dc2.online.net and active) modprobe ip_conntrack_ftp iptables -t filter -A INPUT -p tcp --dport 20 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 21 -j ACCEPT iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t filter -A OUTPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state NEW -d dedibackup-dc2.online.net -j ACCEPT echo - Authorize FTP : [OK] # Mail iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 110 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 143 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT echo - Authorize mail : [OK] # LOGGING if necessary (must be at the end) # From http://www.thegeekstuff.com/2012/08/iptables-log-packets/ #iptables -N LOGGING #iptables -A INPUT -j LOGGING #iptables -A OUTPUT -j LOGGING #iptables -A LOGGING -j LOG --log-prefix "[IPTABLES-DROP]" --log-level debug #iptables -A LOGGING -j DROP #echo - Log enabled ###### End rules ###### echo Iptables / firewall update successfull !
On donne les droits d'execution à ce script :
chmod +x /etc/init.d/iptables
Et on le test AVANT de le démarrer automatiquement… Sinon vous êtes bon pour redémarrer votre serveur en mode secours pour retoucher le fichier… L'avantage de pas le mettre en mode boot automatique c'est que quand vous faites une connerie, suffit de reboot le serveur via l'interface d'admin online.net pour reprendre la main sur le serveur…
Pour activer le script à chaque démarrage,modifiez le script et ajouter ceci après la première ligne #!/bin/bash (plus de update rc, c'est LSBInitScripts maintenant) :
### BEGIN INIT INFO # Provides: iptables # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: # Short-Description: Iptables / firewall configuration ### END INIT INFO
Et on active le boot automatique (voir cette page) :
insserv iptables
Fail2ban est un script surveillant les accès réseau grâce aux logs des serveurs. Lorsqu'il détecte des erreurs d'authentification répétées, il prend des contre-mesures en bannissant l'adresse IP grâce à iptables. Cela permet d'éviter nombre d'attaques bruteforce et/ou par dictionnaire.
Installation :
apt-get install fail2ban
Configuration :
nano /etc/fail2ban/fail2ban.conf
Les services à monitorer sont stockés dans jail.conf. Il est recommandé d'en effectuer une copie nommée jail.local qui sera automatiquement utilisée à la place du fichier exemple.
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
nano /etc/fail2ban/jail.local
Quelques paramètres globaux :
Chaque section possède ses propres paramètres qui prennent le pas sur les globaux s'ils sont mentionnés :
Les filtres par défaut sont stockés dans /etc/fail2ban/filter.d. Ils contiennent en général une instruction failregex suivie d'une expression régulière matchant la détection d'une authentification erronée. Par exemple pour le service Courier :
failregex = LOGIN FAILED, ip=[<HOST>]$
Note : Celle-ci peut être précisée directement dans jail.local à la section appropriée pour prendre le pas sur la directive filter.
Modifiez les ports le cas échéant dans la section ssh si vous avez suivi la recommandation ci-dessus…
enabled = true port = 2222
Après modification de la configuration, n'oubliez pas de redémarrer fail2ban :
service fail2ban restart
Rootkit Hunter est un programme de détection de rootkits. Vous pouvez l'installer grâce à :
apt-get install rkhunter
Il procédera à des détections journalières anti-rootkits et enverra des notifications par e-mail si nécessaire. Il est conseillé de l'installer très tôt car il calcule l'empreinte MD5 des programmes installés afin de détecter d'éventuels changements. Editez /etc/default/rkhunter pour indiquer l'adresse de notification et l'exécution journalière :
nano /etc/default/rkhunter
Modifier ainsi :
REPORT_EMAIL="monitoring@test.com"
En cas de fausses détections positives sur des répertoires ou fichiers existants et sains, éditez /etc/rkhunter.conf pour les ajouter à la liste des éléments autorisés.
nano /etc/rkhunter.conf
Modifier ainsi (dans la partie correspondante avec les autres du genre) :
SCRIPTWHITELIST=/usr/bin/unhide.rb
Pour les distributions ubuntu (utile pour les VM seulement dans la suite du guide), on a quelques warnings supplémentaires à enlever de cette manière :
ALLOWHIDDENDIR="/dev/.udev" ALLOWHIDDENFILE="/dev/.initramfs" ALLOWDEVFILE="/dev/.udev/rules.d/root.rules"
Vous pouvez également utiliser chkrootkit qui est un équivalent.
Dans le domaine de la surveillance / monitoring des serveurs il existe vraiment des tonnes de choses à faire. Sur cette partie, pour l'instant du moins, j'ai décider d'opter pour un service minimum dans le sens ou j'ai une architecture de relativement peu de serveurs et je veux avoir quelque chose qui reste relativement simple. A voir plus tard pour améliorer cette section. Dans tous les cas il faut bien commencer par quelque chose.
Ressources :
Je trouve cette solution intéressante car elle permet d'avoir un moyen de synthétiser et suivre ce qui se passe dans les logs du serveur. Et cela on ne le fait jamais assez alors que pourtant c'est une mine d'or !
Logwatch est par un démon pouvant analyser et résumer les logs générés par les autres services durant la journée pour en détecter d'éventuelles anomalies ou en tirer des statistiques. Il permet d'envoyer un e-mail récapitulatif quotidien à l'administrateur. Son installation est elle aussi très simple grâce à APT et au paquet éponyme :
apt-get install logwatch
La configuration par défaut suffit amplement, il suffit de modifier le destinataire dans le fichier /usr/share/logwatch/default.conf/logwatch.conf. Celui-ci peut se trouver à un autre endroit du disque, n'hésitez pas à vous servir de la commande locate.
nano /usr/share/logwatch/default.conf/logwatch.conf
Modifiez l'option MailTo et tout ce que vous jugerez nécessaire. Par exemple je modifie le format aussi pour qu'il soit plus sympa a lire. Il peut être utile également de régler le niveau de détail.
MailTo = monitoring@test.com Format = html Detail = Med
Vérifiez au besoin la présence de logwatch dans le répertoire /etc/cron.daily/ dont les scripts sont exécutés quotidiennement.
Vous pouvez même lancer l'execution telle que prévue par cron pour voir si tout est OK :
/etc/cron.daily/00logwatch
Monit est une application permettant de surveiller l'état des services (notamment web, ftp, mail, mysql, ssh) par une interface web, et de notifier l'administrateur si nécessaire (trop grande charge cpu, redémarrage, indisponibilité…).
L'installation de Monit se réalise en quelques secondes grâce au paquet éponyme :
apt-get install monit
La configuration de Monit se fait en deux temps. Tout d'abord, autoriser le démarrage du service en éditant /etc/default/monit.
nano /etc/default/monit
L'option START doit être à yes. Il semble que ce soit la valeur par défaut désormais sur les versions récentes.
# You must set this variable to yes for monit to start START=yes
Ensuite, éditer le fichier de configuration /etc/monit/monitrc contenant la description de tous les services à surveiller.
nano /etc/monit/monitrc
Voici un exemple complet. Celui-ci est relativement explicite et à adapter selon votre configuration notamment pour le port SSH (22 par défaut) qui est ici 1337 pour correspondre au précédent tutoriel de configuration.
Note 1 : ici je ne surveille pas des choses comme MySQL ou Apache2 puisque sur le cluster proxmox c'est inutile. De plus je ne surveille pas le serveur FTP puisque je ne souhaite pas en mettre.
Note 2 : Le fichier par défaut est assez fourni, vous pouvez donc prendre exemple dessus et compléter les éléments indiqués ci dessous.
Eléments à modifier (ne pas reprendre juste cela, manquerait des choses sinon) :
# Config
set daemon 120
with start delay 240
set mailserver localhost
set mail-format {
from: monit@$HOST.mondomaine.net
subject: $HOST - Monit : $EVENT $SERVICE
}
set alert monitoring@test.com
set httpd port 8080 and
allow login:password
Puis dans /etc/monit/conf.d/ vous pouvez ajouter les services qui vous intéressent. On peut aussi tout mettre dans monitrc mais je trouve ça peu lisible au final.
nano /etc/monit/conf.d/ssh.conf
# SSH check process sshd with pidfile /var/run/sshd.pid group ssh start program "/etc/init.d/ssh start" stop program "/etc/init.d/ssh stop" if failed host 127.0.0.1 port 1337 protocol ssh then restart if 5 restarts within 5 cycles then timeout
nano /etc/monit/conf.d/postfix.conf
# Postfix check process postfix with pidfile /var/spool/postfix/pid/master.pid group mail start program = "/etc/init.d/postfix start" stop program = "/etc/init.d/postfix stop" if failed port 25 protocol smtp then restart if 5 restarts within 5 cycles then timeout
nano /etc/monit/conf.d/disk.conf
# Disk check device system-root with path /dev/mapper/system-root if space usage > 85% then alert group system
Vous êtes libre d'ajouter tous les services à monitorer sur votre machine (pop3, imap, spamassassin, clamav, fail2ban…). La syntaxe est abordable et les exemples nombreux. Pour vérifier cette syntaxe, utilisez la commande :
/etc/init.d/monit syntax
Si aucun message d'erreur n'est indiqué, vous pourrez ensuite démarrer monit :
service monit start
Vérifiez une nouvelle fois la bonne interprétation de la configuration grâce à monit -v.
J'aurais pu mettre cette partie dans sécurité mais bon la sauvegarde est tellement importante qu'elle mérite un chapitre à elle même. Cette rubrique sera à compléter car avec un serveur proxmox, on a aussi la question de backup des VM qui peut se poser. Ici je ne traiterai pour l'instant que du stricte minimum (vu la config et les options prises sur mes serveurs) à savoir la sauvegarde de la configuration de mes serveurs.
Pour cela je trouve l'utilitaire backup-manager très bien et le tutorial suivi est celui d'Alsacreation (encore :)).
Backup Manager est un outil en ligne de commande pour Linux conçu pour effectuer des sauvegardes quotidiennes de votre système. Il est écrit en bash et Perl, permet de constituer des archives dans plusieurs formats de compression (tar, gzip, bzip2, lzma, dar, zip) et de les exporter vers un serveur FTP ou de les graver automatiquement.
Dans notre cas, nous allons l'installer, et le configurer pour envoyer des archives compressées sur un serveur FTP externe de sauvegarde. Si vous utilisez une Dedibox, vous pourrez ainsi profiter du système dedibackup.
Consultez si nécessaire Configuration d'un serveur dédié de A à Z (Connexion SSH, Accès root, Edition des fichiers en ligne de commande) avant de poursuivre. Installation
Note importante : pour online.net n'oubliez pas d'aller sur la page console.online.net de votre serveur, cliquez sur Sauvegarde notez les paramètres du serveur FTP et enfin éditez les infos de connexion pour initialiser le mot de passe de votre choix.
Backup-manager peut s'installer via apt (pensez à passer en root) :
apt-get install backup-manager
Il sera lancé quotidiennement grâce au démon cron de Linux. Configuration
Editez le fichier /etc/backup-manager.conf
nano /etc/backup-manager.conf
Par défaut, les archives seront placées dans le répertoire /var/archives. Ceci est modifiable par l'instruction
export BM_REPOSITORY_ROOT="/var/archives"
Ce répertoire doit être détenu par root (afin que personne d'autre ne puisse en consulter le contenu).
La durée de conservation des archives est définie (en jours) par :
export BM_ARCHIVE_TTL="15"
Il faut la moduler en fonction de l'espace de sauvegarde disponible et la quantité de données à conserver.
Des fichiers tar.gz seront constitués :
export BM_TARBALL_FILETYPE="tar.gz"
Les répertoires à sauvegarder (vous pouvez avoir plusieurs dossiers séparés par des espaces) :
export BM_TARBALL_DIRECTORIES="/etc"
Dans ce cas, nous sauvegardons l'essentiel de la configuration du système qui se trouve dans /etc.
Il est possible de blacklister certains types de fichiers (ne pas les sauvegarder), ceci est pratique pour ne pas faire exploser la taille des archives :
export BM_TARBALL_BLACKLIST="/var/archives *.mp3 *.avi *.rar *.zip *.ogg *.sql *.tgz *.mpg *.log *.7z"
Configuration de la sauvegarde par FTP
Dans notre cas, nous exportons les archives par FTP :
export BM_UPLOAD_METHOD="ftp" export BM_UPLOAD_HOSTS="dedibackup-dc2.online.net" export BM_UPLOAD_DESTINATION="/"
On précise certaines options FTP (BM_UPLOAD_FTP_DESTINATION est redondant avec la directive BM_UPLOAD_HOSTS par défaut) :
export BM_UPLOAD_FTP_PASSIVE="true"
Dont il faut renseigner l'accès avec login et mot de passe :
export BM_UPLOAD_FTP_USER="votre login" export BM_UPLOAD_FTP_PASSWORD="votre mot de passe"
Nous précisons aussi qu'il faut purger les archives trop anciennes pour être conservées :
export BM_UPLOAD_FTP_PURGE="true"
Avec un BM_UPLOAD_FTP_TTL qui vient de la conf par défaut BM_UPLOAD_FTP_TTL tout comme BM_UPLOAD_FTP_DESTINATION qui vient de BM_UPLOAD_DESTINATION par défaut.
La destination d'upload BM_UPLOAD_FTP_DESTINATION est valorisée par défaut avec BM_UPLOAD_DESTINATION.
Enfin, on oublie pas de désactiver la gravure sur CDROM :
export BM_BURNING_METHOD="none"
Grâce à l'option BM_POST_BACKUP_COMMAND vous pourrez exécuter un script shell une fois la sauvegarde terminée. Ceci est pratique pour envoyer une notification par e-mail lorsque la sauvegarde est terminée ou pour calculer la quantité de données sauvegardées dans /var/archives/. Laissez libre cours à votre imagination ou prenez exemple sur ce script écrit en PHP.
Au préalable, une petite installation de PHP pour ligne de commande s'impose
apt-get install php5-cli
Nous utiliserons donc :
export BM_POST_BACKUP_COMMAND="/etc/backup-manager-post"
En créant le fichier correspondant :
nano /etc/backup-manager-post
Et en y plaçant le code suivant. N'oubliez pas de modifier les deux premières lignes relatives à l'e-mail de destination et au répertoire stockant les archives :
#!/usr/bin/php <?php $dest = array('monitoring@domain.net'); $archives = '/var/archives'; $host = trim(file_get_contents('/etc/hostname')); clearstatcache(); $dir = opendir($archives); if($dir) { $totalsize = ""; $pagetext = ""; while(false !== ($filename = readdir($dir))) { if($filename[0]!='.' && preg_match('/'.date('Ymd').'/',$filename)) { $thefile = $archives.'/'.$filename; $size = exec("ls -l '".$thefile."' | awk '{print $5}'"); if($size>0) { $pagetext.= $filename." (".round($size/1000000000,2)." Go)\n"; } else { $pagetext.= $filename." (? Go)\n"; } $totalsize += $size; } } $pagetext .= "\nTotal : ".round($totalsize/1000000000,2)." Go\n"; } foreach($dest as $d) { mail($d,'['.$host.'] Backup OK',$pagetext); } ?>
Attribuez le droit d'exécution :
chmod +x /etc/backup-manager-post
Et on oublie pas de déclencher nos sauvegardes automatiquement par cron :
nano /etc/cron.daily/backup-manager
Avec ce contenu :
#!/bin/bash # cron script for backup-manager test -x /usr/sbin/backup-manager || exit 0 /usr/sbin/backup-manager
Et on le rend executable
chmod +x /etc/cron.daily/backup-manager
Pour des informations plus détaillées, consultez aussi la documentation officielle de Backup Manager
Pour l'installation dont on a besoin, il va falloir faire un peu de tuning sur le processus d'installation de base notamment le partitionnement. Pour rappel, l'installation de base via la console online.net nous oblige a faire quelque chose de très basique avec toute la place disque disponible affectée au système. Or, nous voulons mettre en place 2 espaces disques pour mettre en place la réplication DRBD.
Comme DRBD fonctionne avec des volumes physiques, soit nous utilisons des disques physiques (si on en a non utilisé) soit on en crée avec LVM sur le disque déjà utilisé. Il se trouve que beaucoup de systèmes linux dont proxmox utilisent déjà LVM sur l'installation de base. Il va donc falloir adapter la configuration existante:
On regarde le montage par défaut :
mount
Ce qui nous intéresse c'est ça
/dev/mapper/system-root on / type ext4 (rw,relatime,errors=remount-ro,barrier=1,data=ordered)
C'est là ou le système est monté par défaut. On va regarder la place disponnible dessus
df -H /
Ce qui donne :
Sys. fich. Taille Util. Dispo Uti% Monté sur /dev/mapper/system-root 952G 1,4G 902G 1% /
C'est ladessus qu'on va devoir travailler.
Cette page de la doc ubuntu est pas mal pour en savoir un peu plus sur LVM.
En gros ce qu'il faut noter c'est qu'il y a un enchainement de 3 couches :
On regarde ce que donnent les volumes physiques :
pvdisplay
--- Physical volume --- PV Name /dev/sda5 VG Name system PV Size 900,29 GiB / not usable 0 Allocatable yes (but full) PE Size 4,00 MiB Total PE 230475 Free PE 0 Allocated PE 230475 PV UUID tG2TXB-uY12-oazV-j0un-AMhW-XNk8-gzvsUn
Puis on regarde les groupes de volumes
vgdisplay
--- Volume group --- VG Name system System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size 900,29 GiB PE Size 4,00 MiB Total PE 230475 Alloc PE / Size 230475 / 900,29 GiB Free PE / Size 0 / 0 VG UUID pSBkN7-xpRm-aDYC-LWwH-M6eS-q1Hh-Gd6dod
Et enfin on regarde les volumes logiques
lvdisplay
--- Logical volume --- LV Path /dev/system/root LV Name root VG Name system LV UUID 48E9TR-LNqs-uP11-kMKY-3UeF-JsLS-Ko3glR LV Write Access read/write LV Creation host, time 62-210-140-177, 2014-05-31 11:27:01 +0200 LV Status available # open 1 LV Size 900,29 GiB Current LE 230475 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0
En résumé, nous avons :
Et c'est /dev/system/root qui contient notre système de fichier monté sur / à la racine de notre système.
Bon, maintenant qu'on y voit mieux sur ce qui se passe, on va passer aux choses sérieuses et c'est un peu casse pied puisqu'il va falloir retoucher l'installation de base…
Pour commencer il faut se connecter à la console web online.net de votre serveur pour le redémarrer en mode secours. Cela permettra de travailler sur le système de fichier sans qu'il soit monté. Sinon impossible de le redimensionner.
Je choisis de prendre environ 100Go pour le système de base, ce qui laisse largement de quoi jouer. Ensuite il me restera donc environ 400Go pour chacun de mes deux futurs volumes DRBD.
Puis en mode secours (on est sur un rescue ubuntu donc on passe avec sudo puisque sur proxmox on devient root avec su et il n'y a pas de sudo) :
sudo e2fsck -f /dev/mapper/system-root sudo resize2fs /dev/mapper/system-root 100G
Et enfin on réduit la taille du LV (inutile de dire qu'il faut avoir fait un backup avant et bien croiser les doigts ensuite) :
sudo lvresize -L 100G /dev/system/root
Là retour sur l'interface online.net pour sortir du mode secours et démarrer votre serveur normalement. C'est le moment de s'éponger le front car si on a foiré un truc avant le système sera probablement irrécupérable…
Ah, le serveur répond, ça doit être pas si mal donc… On vérifie que le système est bien redimensionné.
df -H /
Sys. fich. Taille Util. Dispo Uti% Monté sur /dev/mapper/system-root 106G 1,4G 99G 2% /
Victoire ! Evidemment l'opération est à faire sur chacun des deux serveurs. L'étape suivante sera ensuite de créer des LV pour DRBD.
Je conseille cet excellent article pour avoir un peu de documentation sur le sujet LVM et DRBD.
En gros l'idée ici va être de créer deux volumes logiques dans notre volume group par défaut pour les attribuer ensuite à notre système de réplication entre serveurs via DRBD.
N'oublions pas que nous avons réduit la taille du LV à 100GiB qui est dans un VG de 900,29GiB. Reste donc 800,29GiB à attribuer à nos deux volumes DRBD. Pour faire simple et ne pas tailler les cheveux en 4, on fera donc 400,14GiB d'un côté et 400,15GiB de l'autre.
On crée le premier volume logique dans le VG (qui porte le doux nom de system n'oublions pas) :
lvcreate --name drbd1 --size 400,14G system
Puis le deuxième
lvcreate --name drbd2 --size 400,15G system
Et on vérifie que tout a été créé
lvdisplay
--- Logical volume --- LV Path /dev/system/root LV Name root VG Name system LV UUID 48E9TR-LNqs-uP11-kMKY-3UeF-JsLS-Ko3glR LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 100,00 GiB Current LE 25600 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 --- Logical volume --- LV Path /dev/system/drbd1 LV Name drbd1 VG Name system LV UUID 5TN2B2-5Opz-knwM-K3B3-wZVS-iMqc-qB3toa LV Write Access read/write LV Creation host, time psrv101, 2014-06-24 23:12:25 +0200 LV Status available # open 0 LV Size 400,14 GiB Current LE 102436 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:1 --- Logical volume --- LV Path /dev/system/drbd2 LV Name drbd2 VG Name system LV UUID oiFDTJ-P2hg-z0wp-2vsd-JnCe-GEZ1-bQXScg LV Write Access read/write LV Creation host, time psrv101, 2014-06-24 23:13:38 +0200 LV Status available # open 0 LV Size 400,15 GiB Current LE 102439 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:2
C'est tout bon.
Note importante : Ne pas oublier de créer ces deux volumes sur chacun des deux serveurs physiques. Ils doivent avoir la même taille chacun pour que la réplication soit OK.
Je revoie une nouvelle foi à cet excellent article de Victor Héry dont cette partie est inspirée. Je rabache aussi quelque trucs déjà vu dans les parties précédentes.
Les spécificités pour moi :
Avec les qualités et inconvénients déjà vus plus haut sur ce genre de config. Mais bon si quelqu'un veut me payer le RPN à 1Gbps n'hésitez pas :D
Après une installation de Proxmox, vous devez disposer d'un bridge vmbr0.
Pour utiliser openVPN et simplifier la gestion des adresses IP entre les serveurs, nous allons créer un bridge vmbr1 qui sera utilisé par nos VM pour communiquer entres elles (et aussi pour la réplication DRBD comme je le disais plus haut). C'est une solution simplifiée par rapport a celle proposée par Victor que j'ai déjà utilisé auparavant.
Pour rappel à l'origine Victor propose deux bridges, un pour communiquer avec les passerelles only et un pour que les vm middle communiquent entre elles. A l'usage cependant, j'ai rencontré certains soucis à cette architecture.
En effet les domaines associés à mes serveurs web pointent sur une IP failover que je peux changer de serveur. Sauf que pour que cela fonctionne il faut que chacune de mes VM front puisse accepter cette ip failover. Ce qui sous entend une préparation des ip en double sur chaque vm front et n'est pas sans provoquer des soucis réseau puisque cela me fait monter des interfaces en double avec des ip identiques…
Du coup, je suis obligé de faire une configuration réseau dormante sur chaque VM front et l'activer au besoin ce qui est franchement naze selon moi…
Bref, la nouvelle solution que je me propose de mettre en place est de mettre en place des VM front joignables de n'importes quel seveur physique pour que mes VM middle puissent en profiter ou qu'elles soient également.
Au plus simple donc, il n'y a donc au final qu'un bridge a mettre en place : vmbr1…
Enfin, nous allons mettre en place dummy1, une interface “bidon” va permettre d'avoir une interface fixe pour “brancher” openvpn, qui a besoin d'une interface réseau physique pour se lancer correctement au démarrage du serveur.
Assez basique, il suffit d'aller dans la console web online.net et créer un groupe RPN entre vos 2 serveurs dédiés. Je ne m'attarderai pas dessus.
Partant de là vos serveurs pourront causer directement ensemble sur leur deuxième interface physique une fois qu'elle sera configurée.
Pour avoir les ip de ces interfaces, rendez vous sur la console web du serveur.
Nous allons commencer par créer l'interface dummy (un peu particulière) nécessaire à OpenVPN. De base, Proxmox peut utiliser une interface dummy pour des usages internes, nous allons donc utiliser une deuxième par précaution :
echo "options dummy numdummies=2" > /etc/modprobe.d/dummy.conf
modprobe dummy
Pour vérifier que les interfaces ont bien été créées, tapez la commande suivante :
ifconfig -a | grep Link | grep -v inet6
Qui doit vous renvoyer quelque chose comme ça :
dummy0 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx dummy1 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx eth0 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx lo : Link encap:Local Loopback vmbr0 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
Nous allons aller toucher au fichier /etc/network/interfaces.
Avant ça, sauvegardez le fichier :
cpav /etc/network/interfaces /etc/network/interfaces.original
Puis éditez le :
nano /etc/network/interfaces
On fait un peu de ménage sur l'existant (commentaires pour s'y retrouver) et on active le RPN en dhcp pour pouvoir l'utiliser. Normalement il est sur eth1. Voir la documentation online.net.
# The loopback network interface
auto lo
iface lo inet loopback
# Main network interface used with vmbr0
iface eth0 inet manual
# Bridge with the main interface for public network
auto vmbr0
iface vmbr0 inet static
address IP_SERVEUR_PHYSIQUE_1
netmask 255.255.255.0
gateway GW_SERVEUR_PHYSIQUE_1
bridge_ports eth0
bridge_stp off
bridge_fd 0
# RPN Interface
auto eth1
iface eth1 inet dhcp
Ajoutez vmbr1 qui servira pour consruire le réseau entre les VM :
# Bridge to communicate between VM auto vmbr1 iface vmbr1 inet static address 192.168.100.1 netmask 255.255.255.0 bridge_ports dummy1 bridge_stp off bridge_fd 0 post-up route add -net 224.0.0.0 netmask 240.0.0.0 dev vmbr1
Je prends 192.168.100.1 pour le serveur principal et 192.168.100.2 pour le secondaire.
Pour appliquer les modifications, effectuez un :
service networking restart
Pour vérifier que les nouvelles interfaces fonctionnent correctement, vous pouvez les pinguer sur leurs serveurs respectifs :
ping 192.168.100.1
ping 192.168.120.2
Une fois le VPN monté (plus tard) on pourra joindre toutes les IP depuis n'importe quel serveur.
Pour rappel, j'ai choisi de faire en sorte d'avoir les échanges d'infos entre les noeuds du cluster via le réseau RPN. Il faut pour cela faut configurer les hosts qui seront utilisés par proxmox pour qu'ils soient résolus avec l'IP dans le réseau qui nous intéresse (ici le RPN) :
nano /etc/hosts
Mettez bien le nom du host (ici machine1 et machine2) de votre serveur sur l'ip du RPN (si c'est ce réseau que vous voulez utiliser) :
# Localhost 127.0.0.1 localhost IP_SERVEUR_PHYSIQUE_1 sd-yyyyy.dedibox.fr sd-yyyyy machine1.wan machine1.mondomaine.net IP_RPN_SERVEUR_PHYSIQUE_1 machine1 machine1.rpn 192.168.100.2 machine1.vpn # Other proxmox physical node IP_SERVEUR_PHYSIQUE_2 sd-yyyyy.dedibox.fr sd-yyyyy machine2.wan machine2.mondomaine.net IP_RPN_SERVEUR_PHYSIQUE_2 machine2 machine2.rpn 192.168.100.2 machine2.vpn
Pour bootlogd, plus besoin de configuration depuis Wheezy comme vu dans cet article.
On est parti ! Tout ce qui était avant va vous servir :)
Installons OpenVPN pour commencer :
apt-get install openvpn
Faites ceci sur tous vos serveurs.
Sur le serveur PRA, le serveur principal d'OpenVPN, nous allons générer les certificats serveurs et clients.
cpav /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa/
cd /etc/openvpn/easy-rsa/
cpav vars vars.original
Editez le fichier vars, tout à la fin du fichier, pour modifier les variables globales. Ainsi votre génération de clef se fera automatiquement. Sinon, vous devrez indiquer les informations à chaque génération.
nano /etc/openvpn/easy-rsa/vars
Version un peu bourrin :
export KEY_COUNTRY="FR" export KEY_PROVINCE="FR" export KEY_CITY="Paris" export KEY_ORG="mondomaine.net" export KEY_EMAIL="me@myhost.mydomain" export KEY_CN=mondomaine.net export KEY_NAME=mondomaine.net export KEY_OU=mondomaine.net export PKCS11_MODULE_PATH=mondomaine.net export PKCS11_PIN=1234
Puis :
source ./vars
Vous verrez ceci :
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys
C'est parti :
./clean-all ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time ........................................................+...... ..+............+............................................... ............................................................... ...+............................................++*++*++*
./pkitool --initca
Using CA Common Name: Mon organisation CA Generating a 1024 bit RSA private key ...++++++ ................++++++ writing new private key to 'ca.key' -----
La clé serveur sera utilisée sur la machine 1.
./pkitool --server server
openvpn --genkey --secret ./keys/ta.key
La clé client sera utilisée sur la machine 2.
Comme indiqué sur ce site nous allons créer deux certificats ayant le même sujet (même DN), passez la valeur “unique_subject” à “no” dans le fichier “index.txt.attr” (qui se trouve dans le dossier keys) de votre autorité de certification. C'est mal faudra améliorer ça mais on verra plus tard.
Sans cette modification votre fichier CRT sera vide suite a une erreur de ce type
failed to update database TXT_DB error number 2
On génère la clé :
./pkitool client-machine2
Vous pouvez également en profiter pour générer d'autres clefs clients si vous souhaitez vous connecter vous-même au VPN, pour sécuriser à fond vos accès SSH par exemple.
cd /etc/openvpn/easy-rsa/keys/
tar cvzf /root/server-keys.tar.gz server.crt server.key ca.crt dh1024.pem ta.key
tar cvzf /root/client-machine2-keys.tar.gz client-machine2.crt client-machine2.key ca.crt ta.key
Comme nous ne mettons pas en place de triangle VPN comme Victor le suggère, pas faute de moyens et parceque nous ne faisons pas de HA faute de moyens et de fencing, on ne configurera qu'une seule machine physique en serveur openvpn. L'autre sera donc forcement configurée en client :)
Importez le fichier de configuration par défaut :
cd /etc/openvpn/
On crée les dossiers utiles :
mkdir logs mkdir scripts
Et on s'occupe du fichier de configuration :
zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > server.conf
Le fichier doit ressemble à ça sans ses commentaires (et en changeant les valeurs style port à vote convenance) :
cat server.conf | grep -v -e '^;' | grep -v -e '^#' | grep -v -e '^$'
local IP_PUBLIQUE_SERVEUR port 4450 proto tcp dev tap1 ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh1024.pem server-bridge XXX.XXX.XXX.XXX 255.255.255.0 YYY.YYY.YYY.YYY TTT.TTT.TTT.TTT client-to-client duplicate-cn keepalive 10 120 tls-auth /etc/openvpn/ta.key 0 # This file is secret comp-lzo max-clients 4 user nobody group nogroup persist-key persist-tun status logs/openvpn-status.log log-append logs/openvpn.log verb 3 tls-server script-security 2 up "/etc/openvpn/scripts/up.sh" down "/etc/openvpn/scripts/down.sh"
Attention, ici on choisit de fonctionner en UDP ce qui représente un risque en fiabilité par rapport à TCP. Cependant, je considère qu'étant donné la topologie réseau entre mes serveurs (réseau local d'un hébergeur pro) c'est acceptable. D'autant plus que le passage à UDP réduit l'overhead réseau et surtout accélère la vitesse / augmente la bande passante dispo.
Les choses à modifier selon le serveur :
Ces scripts vont permettre d'ajouter l'interface OpenVPN (tap1) au bridge vmbr1 à chaque démarrage du serveur VPN. Et bien sûr de le retirer à l'arrêt du serveur VPN (faisons les choses bien)
Ces scripts seront sensiblement différents pour les clients, nous verrons ça plus bas.
nano /etc/openvpn/scripts/up.sh
#!/bin/bash /sbin/ifconfig vmbr1 promisc /sbin/ifconfig tap1 up promisc /sbin/brctl addif vmbr1 tap1
nano /etc/openvpn/scripts/down.sh
#!/bin/bash /sbin/brctl delif vmbr1 tap1 /sbin/ifconfig tap1 down -promisc /sbin/ifconfig vmbr1 -promisc
Et on oublie pas de donner le droit d'execution :
chmod +x etc/openvpn/scripts/*
Le serveur devra disposer du set de clef serveur que nous avons généré plus haut (mais dans le dossier spécifique). Sans quoi, il n'acceptera pas les connexions du client.
cd /etc/openvpn
tar xvzf /root/server-keys.tar.gz
Une fois ceci fait, vous pouvez redémarrer OpenVPN :
service openvpn restart
Normalement, il doit démarrer sans erreurs des deux côtés. Les logs s'écrivent dans /etc/openvpn/openvpn.log
Un démarrage réussit doit se terminer par
Initialization sequence completed
Sinon, vérifiez bien les adresses IP que vous avez indiquée (problème de bind) et la synthaxe des paramètres dans le fichier de conf (problème de “unknown parameter”)
A ce stade, nous avons uniquement le serveurs VPN qui tourne Il va vous falloir configurer le client qui s'y connecte c'est a dire machine2.
Importez le fichier de configuration par défaut :
cd /etc/openvpn/
On crée les dossiers utiles :
mkdir logs mkdir scripts
Et on s'occupe du fichier de configuration :
cpav /usr/share/doc/openvpn/examples/sample-config-files/client.conf .
Pour une configuration idéale (d'après mes tests de robustesse personnels), le fichier doit ressemble à ça sans ses commentaires (et en changeant les valeurs style port à vote convenance) :
cat client.conf | grep -v -e '^;' | grep -v -e '^#' | grep -v -e '^$'
Voici le fichier de configuration :
client dev tap1 proto udp remote IP_PUBLIQUE_SERVEUR_1 port PORT_VPN resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert client-machine2.crt key client-machine2.key ns-cert-type server tls-auth ta.key 1 comp-lzo verb 3 log-append logs/client.log script-security 2 up "/etc/openvpn/scripts/up-client.sh" down "/etc/openvpn/scripts/down-client.sh" keepalive 30 120 float
Les paramètres à adapter :
Les fichiers up.sh et down.sh sont différents pour les clients. Comme le serveur principal possède déjà up.sh et down.sh, on les nomme up-client.sh et down-client.sh pour qu'ils ne se marchent pas dessus (quelle imagination !) et on les mets dans le dossier /etc/openvpn/scripts.
nano /etc/openvpn/scripts/up-client.sh
#!/bin/bash /sbin/ifconfig vmbr1 promisc /sbin/ifconfig tap1 up promisc /sbin/brctl addif vmbr1 tap1 /sbin/ifconfig tap1 0
nano /etc/openvpn/scripts/down-client.sh
#!/bin/bash /sbin/ifconfig vmbr1 -promisc
La principale différence est le nom des interfaces à bridger (tap1 dans mon cas). Le down client ne doit également pas sortir le tap1 du bridge, sinon il risque de générer une erreur qui va bloquer la tentative de connexion en boucle du client.
Et on oublie pas de donner les droits d'execution :
chmod +x /etc/openvpn/scripts/*
Bien, il ne reste plus qu'à récupérer la clef openvpn à qui de droit (en ayant au préalable bougé les clés de du dossier root vers le dossier user que vous utiliserez pour scp et sans oublier les droits + ménage ensuite) :
scp -P portssh user@IP_SERVEUR_PHYSIQUE_1:~/client-psrv102-keys.tar.gz .
Et on oublie pas de bouger les clés dans le dossier root et ensuite faire le ménage !
Puis extrayez les clefs dans /etc/openvpn :
cd /etc/openvpn
tar xvzf /root/client-machine2-keys.tar.gz
Et enfin, redémarrez openvpn.
La connexion va s'établir. Là encore, les logs s'écrivent dans /etc/openvpn, dans le fichier client.log spécifé dans le fichier de configuration.
Si tout se passe bien, vous pourrez y voir apparaitre un “Initialization sequence completed”.
C'est également dans ce fichier que vous pouvez vérifier si la reconnexion se fait bien.
Enfin vous pouvez vérifier que le ping se passe bien désormais sur les 2 machines :
ping 192.168.100.1 ping 192.168.100.2
Nous avons donc un système de cluster avec 2 noeuds physiques. Nous avons mis en place deux volumes DRBD dans les parties précédentes. Chaque serveur contiendra deux volumes DRBD mais un seul à la fois sera utilisé en écriture. Ce système évite normalement les cas de split brain qui sont généralement d'une grande tristesse à résoudre vu que cela implique en général de la perte de données…
Pour cette partie, on s'appuiera en grande partie sur la documentation DRBD de proxmox. La partie nested LVM a été vue finalement plus haut avec le travail LVM qu'on à fait en amont.
Rien de plus simple et sur chacun des serveurs physiques :
apt-get install drbd8-utils
On remplace /etc/drbd.d/global_common.conf par le contenu suivant :
global { usage-count no; }
common {
syncer { rate 30M; verify-alg md5; }
handlers { out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root"; }
}
Le rate c'est à dire la bande passante utilisée est très important à configurer correctement. Plus d'informations sur cette page. Ici le 30 est en Mbyte et non bit. La valeur ici par défaut correspond à une liaison Gibabit !! Avec un coef maxi de 30% de la bande passante utilisée.
La partie disk doit correspondre aux volumes LVM que nous avons créé spécialement pour DRBD plus haut.
Pour notre premier volume DRBD on crée le fichier de configuration et sur chacun des serveurs (adaptez la conf avec le nom de vos machines, éventuellement les IP etc…) /etc/drbd.d/r1.res :
# From http://pve.proxmox.com/wiki/DRBD#Start_DRBD
resource r1 {
protocol C;
startup {
wfc-timeout 0; # non-zero wfc-timeout can be dangerous (http://forum.proxmox.com/threads/3465-Is-it-safe-to-use-wfc-timeout-in-DRBD-configuration)
degr-wfc-timeout 60;
become-primary-on both;
}
net {
cram-hmac-alg sha1;
shared-secret "my-secret";
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
#data-integrity-alg crc32c; # has to be enabled only for test and disabled for production use (check man drbd.conf, section "NOTES ON DATA INTEGRITY")
}
on MACHINE1 {
device /dev/drbd1;
disk /dev/system/drbd1;
address 192.168.100.1:7788;
meta-disk internal;
}
on MACHINE2 {
device /dev/drbd1;
disk /dev/system/drbd1;
address 192.168.100.2:7788;
meta-disk internal;
}
}
Pour notre second volume DRBD on crée le fichier de configuration et sur chacun des serveurs /etc/drbd.d/r2.res :
# From http://pve.proxmox.com/wiki/DRBD#Start_DRBD
resource r2 {
protocol C;
startup {
wfc-timeout 0; # non-zero wfc-timeout can be dangerous (http://forum.proxmox.com/threads/3465-Is-it-safe-to-use-wfc-timeout-in-DRBD-configuration)
degr-wfc-timeout 60;
become-primary-on both;
}
net {
cram-hmac-alg sha1;
shared-secret "my-secret";
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
#data-integrity-alg crc32c; # has to be enabled only for test and disabled for production use (check man drbd.conf, section "NOTES ON DATA INTEGRITY")
}
on MACHINE1 {
device /dev/drbd2;
disk /dev/system/drbd2;
address 192.168.100.1:7789;
meta-disk internal;
}
on MACHINE1 {
device /dev/drbd2;
disk /dev/system/drbd2;
address 192.168.100.2:7789;
meta-disk internal;
}
}
On démarre DRBD sur chaque serveur mais ce ne sera pas suffisant pour avoir la conf complète :
service drbd start
Note importante : bon pour moi ca a été le souk à ce stade. J'ai beau suivre le tuto proxmox il m'a insulté au démarrage. Finalement j'ai fait les étapes suivantes et j'ai bidouillé et cela a fini par fonctionner mais c'est super moche. A voir comment faire mieux
On crée nos ressources sur chaque serveur
drbdadm create-md r1 drbdadm create-md r2
On monte les volumes DRBD
drbdadm up r1 drbdadm up r2
On regarde l'état DRBD sur les différents noeud et on constate que c'est le souk (pas de synchro initiale donc tout est en vrac) :
cat /proc/drbd
On a un truc qui ressemble à ça pour chacun des noeuds :
1: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:419565012
2: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:419577300
Pour remédier à cela on va démarrer la synchro initiale en passant un noeud en primaine pour chacune des ressources (donc on ne fait pas ça sur les 2 !). Cela va lui permettre de prendre la main et la réplication va pouvoir démarrer) :
drbdadm -- --overwrite-data-of-peer primary r1 drbdadm -- --overwrite-data-of-peer primary r2
Selon la taille du disque cela va être assez long donc on suit cela jusqu'à ce que ce soit terminé
watch cat /proc/drbd
On devrait avoir une jauge de progression comme ceci :
1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
ns:12539660 nr:0 dw:0 dr:12548504 al:0 bm:765 lo:1 pe:4 ua:64 ap:0 ep:1 wo:b oos:407025748
[>....................] sync'ed: 3.0% (397484/409728)M
finish: 3:33:23 speed: 31,784 (27,680) K/sec
2: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
ns:11591568 nr:0 dw:0 dr:11600408 al:0 bm:707 lo:1 pe:4 ua:64 ap:0 ep:1 wo:b oos:407986132
[>....................] sync'ed: 2.8% (398420/409740)M
finish: 4:44:19 speed: 23,892 (25,756) K/sec
Evidemment si vous avez de gros diques, la réplication initiale peut prendre *beaucoup de temps* (plusieurs heures) donc il vaut mieux prévoir à l'avance :). Une fois terminé on stope DRBD sur chaque noeud :
service drbd stop
Puis on les redémarre sur chaque noeud :
service drbd start
Et on devrait voir désormais que les deux noeuds sont en primaire / primaire et up to date.
cat /proc/drbd
Ce qui donne quelque chose du genre si tout va bien :
1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
ns:0 nr:0 dw:0 dr:664 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
2: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
ns:0 nr:0 dw:0 dr:664 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
Nous avons donc maintenant deux volumes DRBD synchronisés entre eux sur les deux serveurs. En l'état ils ne servent à rien pour notre cluster proxmox. En effet, promox peut utiliser LVM pour monter des VM mais seulement des volumes group (VG). On va donc devoir procéder à la création de ces VG sur nos volumes DRBD pour pouvoir les donner à manger à promox.
Sur UN SEUL des deux systèmes (pas besoin de faire sur les deux puisque c'est répliqué) on crée un volume physique sur les ressources DRBD qu'on a configuré :
pvcreate /dev/drbd1 pvcreate /dev/drbd2
On vérifie que c'est bien créé :
pvscan
Ce qui donne ceci :
PV /dev/sda5 VG system lvm2 [900,29 GiB / 0 free] PV /dev/drbd1 lvm2 [400,13 GiB] PV /dev/drbd2 lvm2 [400,14 GiB] Total: 3 [1,66 TiB] / in use: 1 [900,29 GiB] / in no VG: 2 [800,27 GiB]
Et vous pouvez même lancer un petit pvscan sur l'autre système pour vérifier que vos volumes sont apparus aussi, comme par magie :)
Enfin, sur un seul des noeuds (toujours pareil l'autre ca se fera tout seul grace a la répli) on créé un volume group sur chaque volume physique. Ce sont ces VG qui seront utilisé par proxmox :
vgcreate pve-drbd1 /dev/drbd1 vgcreate pve-drbd2 /dev/drbd2
On vérifie (sur chacun des noeuds) que c'est bien créé :
vgscan
Ce qui doit donner quelque chose comme ça :
Reading all physical volumes. This may take a while... Found volume group "system" using metadata type lvm2 Found volume group "pve-drbd2" using metadata type lvm2 Found volume group "pve-drbd1" using metadata type lvm
Enfin, pour ajouter ces volumes groups dans proxmox, rendez vous sur l'interface web, puis dans la rubrique Stockage cliquez sur Ajouter et LVM. Vous devriez pouvoir voir vos volumes précédemment créés. A noter que puisque ce sont des volumes répliquez vous devez cocher l'option shared sur ces volumes pour évider que proxmox se plante lors des migrations de VM. Choisissez également pour chaque volume les 2 noeuds et répétez l'opération pour les deux DRBD que nous avons créé.
Pour notre configuration, nous allons faire passer la configuration cluster proxmox sur le réseau RPN. Cela permettra de soulager les interfaces primaires déjà utilisé pour le traffic public et le VPN qui contient lui même la partie DRBD ainsi que les communications entre nos VM.
Le problème est que le réseau RPN ne permet pas non plus le multicast. Notre VPN le permet mais comme dit plus haut il est bien assez chargé comme ça. Reste donc la possibilité de monter un deuxième VPN sur le réseau RPN pour utiliser le multicast (non abordé dans ce guide puisque ce n'est pas le choix retenu d'autant plus que le débit du réseau RPN de base est limité à 100Mbps).
Pour tester si le réseau dispose bien du multicast, installez l'outil suivant :
apt-get install ssmping
Il vous faut lancer sur un serveur pour le mettre en écoute :
ssmpingd
Puis depuis un autre, lancez le test :
asmping 224.0.2.1 IP_SERVEUR_TEST
Vous devez voir passer sur le serveur en écoute des messages de ce type :
asmping joined (S,G) = (*,224.0.2.234) pinging IP_SERVEUR_TEST from IP_SERVEUR_SOURCE unicast from IP_SERVEUR_TEST, seq=1 dist=0 time=38.699 ms multicast from IP_SERVEUR_TEST, seq=1 dist=0 time=76.405 ms unicast from IP_SERVEUR_TEST, seq=2 dist=0 time=38.802 ms multicast from IP_SERVEUR_TEST, seq=2 dist=0 time=76.238 ms
Les lignes importantes à repérer sont celles du multicast, que vous devez impérativement constater pour le bon fonctionnement du cluster !
Dans notre cas, nous n'aurons pas de multicast mais du unicast pour proxmox. Cependant, ce n'est pas un souci dans notre cas puisque nous n'avons que 2 noeuds. Il est donc tout à fait possible et sans surcoût de ne faire qu'un simple unicast. Et heureusement c'est possible en suivant cette documentation.
Par contre il faut bien comprendre qu'utiliser le mode unicast avec plus de deux noeuds peut être contre productif en terme d'utilisation réseau. En effet au lieu d'avoir des messages diffusés une fois à tout les noeuds il devra y avoir de la communication bidirectionnelle entre chaque noeud avec toute la répétition et non fiabilité d'un point de vue cluster HA que cela représente.
Nous verrons comment faire plus loin pour activer le mode unicast car il faut d'abord créer le cluster.
C'est le bon moment pour vérifier le fichier /etc/hosts. Pour rappel, le nom de vos hosts utilisé pour le cluster doivent êtres associées aux ip du réseau que vous voulez utiliser. Ici si vous vous basez sur mes choix, vous devez avoir indiqué l'adresse IP du du host correspondant à l'IP du RPN.
Pour le cluster, nous allons effectuer sa création depuis le premier serveur physique et nous y ajouterons les autres noeuds.
Je vous rappelle qu'il ne doit y avoir aucune VM sur les serveurs ! Si votre système a déjà des VM en fonctionnement, migrez les temporairement sur le premier serveur (celui ou vous créez le cluster) le temps de créer le cluster. Cette limitation a pour but de s'assurer qu'aucun VMID ne sera en conflit au sein du cluster.
Le nom du cluster est important, dans le sens où une fois le cluster créé, vous ne pourrez plus changer ce nom. Choisissez le bien !
pvecm create NOM_DU_CLUSTER
qui doit vous renvoyer :
Restarting pve cluster filesystem: pve-cluster[dcdb] notice: wrote new cluster config '/etc/cluster/cluster.conf' . Starting cluster: Checking if cluster has been disabled at boot... [ OK ] Checking Network Manager... [ OK ] Global setup... [ OK ] Loading kernel modules... [ OK ] Mounting configfs... [ OK ] Starting cman... [ OK ] Waiting for quorum... [ OK ] Starting fenced... [ OK ] Starting dlm_controld... [ OK ] Tuning DLM kernel config... [ OK ] Unfencing self... [ OK ]
Puis on active le mode unicast, comme spécifié dans cette page
cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new
On modifie la nouvelle configuration pour activer le mode unicast :
nano /etc/pve/cluster.conf.new
En ajoutant la nouvelle directive transport=“udpu” :
<cman keyfile="/var/lib/pve-cluster/corosync.authkey" transport="udpu"> </cman>
Pensez également aussi a incrémenter “config_version” ce qui garantira l'application des modifications.
Vous pouvez valider la configuration avec la commande suivante :
ccs_config_validate -v -f /etc/pve/cluster.conf.new
La configuration sera à activer uniquement via l'interface web, dans la partie HA. Vous pouvez vérifier la syntaxe et l'appliquer. Elle sera ensuite prise en compte par tous les noeuds.
Enfin, depuis le second serveur physique on passe cette commande pour qu'il s'ajoute dans le cluster configuré sur le premier serveur physique :
pvecm add 192.168.100.1
Cette commande doit vous renvoyer à peu près la même chose qu'au dessus, lors de la création du cluster sur le premier noeud.
La commande pvecm vous permettra d'avoir plusieurs infos sur le cluster.
pvecm n
vous donnera un aperçu des nodes (date de connexion, état, etc)
pvecm s
vous donnera des informations sur le cluster lui-même (état du qorum, nombre de node, nombre de vote, etc)
Nous verrons plus tard des commandes plus spécifiques au HA.
La première étape consiste à récupérer les images ISO de la distribution que vous choisirez pour votre installation.
Pour ma part je pars une ubuntu dernière version pour architecture 64 bits.
http://releases.ubuntu.com/14.04/ubuntu-14.04-server-amd64.iso
On va placer cette image (sur chaque serveur physique) dans le dossier dédié à accueillir les images iso pour que proxmox puisse les retrouver lorsqu'on va vouloir installer :
cd /var/lib/vz/template/iso
On récupère l'iso :
wget http://releases.ubuntu.com/14.04/ubuntu-14.04-server-amd64.iso
Pour vérifier votre ISO, allez sur l'IHM web proxmox puis cliquez sur le disque local de vos serveurs physiques et enfin choisissez l'onglet contenu. Vous devrez voir votre iso.
En quelques mots, l'architecture de serveurs virtuels que j'adopte :
Je n'ai pas choisi de faire une architecture n-tiers du avec un back parce que vu ce que j'héberge cela m'a semblé un peu trop luxueux. De plus ça multiplie les install les administrations et les efforts. Par contre le garde le principe du front et du middle séparés comme ça je protège mes applications avec un front.
Rendez vous sur l'interface WEB proxmox et cliquez sur “Créer VM”. L'avantage du cluster c'est que vous n'avez pas besoin d'aller sur chaque noeud pour faire l'opération. Vous pourrez créer les VM sur chaque serveur physique depuis la même interface. Il faudra simplement prendre garde de bien choisir le bon noeud pour chaque VM créée.
Général :
OS :
CD/DVD :
Disque Dur :
CPU :
Mémoire :
Réseau :
On valide et la VM est créée. On renouvèle pour la seconde VM front sur le second serveur physique mais en adaptant la configuration. Les VM sont créées mais pas encore démarrées.
Par défaut, on a configuré une carte réseau sur vmbr0 qui permet d'accéder au réseau public.
Or nous avons configuré sur nos serveurs physiques un second bridge vmbr1 pour le réseau interne des VM.
Nous allons donc aller sur la VM fraichement créée puis onglet matériel, Ajouter et enfin Carte réseau. Nous ajoutons une nouvelle carte réseau configurée sur vmbr1.
Avant toute choses, n'oubliez pas avant de régler dans les options de la VM la disposition du clavier à français sinon bonjour le qwerty dans la console VNC !
Selon ce que vous souhaitez, n'oubliez pas, toujours dans l'ihm web partie Options, de configurer votre VM pour qu'elle démarre automatiquement au démarrage du serveur. Vous pouvez également configurer (conseillé) l'ordre de démarrage avec un numéro d'ordre et un temps de délai. Pour plus d'informations vous pouvez consulter cette page
Vos VM ne sont pas encore dispo sur le réseau (et pas installées d'ailleurs). Mais proxmox fournit un accès console direct à vos VM. Il suffit d'aller sur l'IHM web de choisir votre VM et cliquer sur console. Attention il vous faudra un plugin java qui tourne.
Cliquez sur démarrer pour démarrez la VM et faites l'install comme si c'était chez vous.
Lors de l'installation, pour la partie réseau, choisissez l'option configurer plus tard. On le fera manuellement dans la partie suivante.
Enfin une fois que c'est fini, on oublie pas de retourner sur l'IHM web proxmox, choisir sa VM, cliquer sur le CDROM puis éditer et enfin mettre sur none. Plus besoin de l'iso d'install ubuntu puisqu'on vient de la terminer.
On le fera manuellement notamment en nous basant sur la documentation de online.net dans la partie proxmox.
On commence par désactiver ipv6 qu'on utilise pas comme indiqué dans la doc unbuntu :
nano /etc/sysctl.conf
# Disable ipv6 net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1
Et enfin :
echo "options ipv6 disable=1" > /etc/modprobe.d/disable-ipv6.conf
Ensuite on configure le réseau :
sudo nano /etc/network/interfaces
Avec de quoi atteindre le réseau public fourni par vmbr0 et le réseau interne fourni par vmbr1 :
# The loopback network interface auto lo iface lo inet loopback # To access vmbr0 for public network auto eth0 iface eth0 inet static address IP_FAILOVER_VM_1 netmask 255.255.255.255 broadcast IP_FAILOVER_VM_1 dns-nameservers 62.210.16.6 62.210.16.7 post-up route add IP_SERVEUR_PHYSIQUE_1_SANS_LA_FIN.1 dev eth0 post-up route add default gw IP_SERVEUR_PHYSIQUE_1_SANS_LA_FIN.1 post-down route del IP_SERVEUR_PHYSIQUE_1_SANS_LA_FIN.1 dev eth0 post-down route del default gw IP_SERVEUR_PHYSIQUE_1_SANS_LA_FIN.1 # To access vmbr1 for internal network auto eth1 iface eth1 inet static address 192.168.100.11 netmask 255.255.255.0
Pour eth0, je laisse les DNS qui sont ceux de online.net (les nouveaux, vu sur cette page).
La gateway du réseau publique correspond à l'ip physique du dédié mais qu'on termine par .1.
La configuration est a adapter en fonction de vos spécificités.
On redémarre les VM et on vérifie que les accès réseau fonctionnent sur les interfaces publiques comme internes.
Sur chaque VM, afin d'éviter de passer par l'accès console via l'IHM proxmox, on install openssh et ses petits amis :
<sudo bash> sudo apt-get install ssh </code>
Et on oublie pas un bon passage par la case mise à jour :
sudo apt-get install update sudo apt-get install upgrade
Enfin, le plus important ON SECURISE ET ON BACKUP ses serveurs VM. Je vous renvoie aux parties similaires traitées plutôt dans ce guide. On peut les reprendre en grande partie à part quelques adaptations que nous verrons plus tard.
Même combat également pour la configuration du serveur mail, des DNS etc etc. Voir les parties précédentes du guide.
Pour rappel nous sommes sur des VM front. Elles vont donc notamment assurer le NAT de tout le traffic réseau des VM middle. Il convient donc de construire une configuration iptables qui va bien.
Pour activer le mode routeur sur notre serveur middle, on doit activer l'ip forwarding.
sudo nano /etc/sysctl.conf
Et activer cette ligne
net.ipv4.ip_forward=1
Enfin on prépare la configuration firewall / iptables. Elle ressemble beaucoup à ce qu'on a vu précédemment mais version plus limitée et avec une commande supplémentaire pour l'ip forwarding.
sudo nano /etc/init.d/iptables
#!/bin/bash echo Setting iptables / firewall rules... # # Dedibox iptables / firewall configuration # # http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot # http://wiki.debian.org/LSBInitScripts # http://documentation.online.net/fr/serveur-dedie/tutoriel/iptables-netfilter-configuration-firewall # http://www.alsacreations.com/tuto/lire/622-Securite-firewall-iptables.html # # Modifications alban.montaigu # ###### Start Initialisation ###### # Empty current tables iptables -t filter -F iptables -t filter -X echo - Empty current tables : [OK] # No input connection iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP echo - No input connection : [OK] # No output connection iptables -t filter -P OUTPUT DROP echo - No output connection : [OK] # Authorize SSH iptables -t filter -A INPUT -p tcp --dport 2222 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 2222 -j ACCEPT echo - Authorize SSH : [OK] # Authorize interfaces on internal network (enable multicast) iptables -A INPUT -i eth1 -j ACCEPT iptables -A FORWARD -i eth1 -j ACCEPT iptables -A OUTPUT -o eth1 -j ACCEPT echo - Authorize eth1 [OK] # Do not break established connections iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT echo - Do not break established connections : [OK] ###### End Inialisation ###### ##### Start Rules ###### # Authorize DNS, FTP, HTTP, NTP iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT echo - Authorize DNS, FTP, HTTP, NTP : [OK] # Authorize loopback iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A OUTPUT -o lo -j ACCEPT echo - Authorize loopback : [OK] # Authorize ping iptables -t filter -A INPUT -p icmp -j ACCEPT iptables -t filter -A OUTPUT -p icmp -j ACCEPT echo - Authorize ping : [OK] # HTTP iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 8443 -j ACCEPT echo - Authorize HTTP : [OK] # Monit iptables -t filter -A INPUT -p tcp --dport 8080 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 8080 -j ACCEPT echo - Authorize monit : [OK] # FTP (passive dedibackup-dc2.online.net and active) modprobe ip_conntrack_ftp iptables -t filter -A INPUT -p tcp --dport 20 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 21 -j ACCEPT iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t filter -A OUTPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state NEW -d dedibackup-dc2.online.net -j ACCEPT echo - Authorize FTP : [OK] # Mail iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 110 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 143 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT echo - Authorize mail : [OK] ###### Start NAT ###### # NAT to run as a gateway iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT echo - Activate NAT : [OK] ###### End NAT ###### # LOGGING if necessary (must be at the end) # From http://www.thegeekstuff.com/2012/08/iptables-log-packets/ #iptables -N LOGGING #iptables -A INPUT -j LOGGING #iptables -A OUTPUT -j LOGGING #iptables -A LOGGING -j LOG --log-prefix "[IPTABLES-DROP]" --log-level debug #iptables -A LOGGING -j DROP #echo - Log enabled ###### End rules ###### echo Iptables / firewall update successfull !
On donne les droits d'execution à ce script :
sudo chmod +x /etc/init.d/iptables
Et seulement quand on est pret et qu'on a testé on le configure pour s'executer au démarrage :
sudo update-rc.d iptables defaults
Et on reboot.
Pour cette partie, je fais faire court, le principe reste le même que celui des VM front. Vous pouvez donc vous y référer.
Evidemment ce sont des VM middle, elles doivent être donc plus caustaud. C'est bien sur et encore une fois à adapter en fonction de vos besoins.
Pour ma part, pour un site à faible fréquentation, je prends :
A noter que la configuration réseau sera différente. Nous prendrons qu'une seule interface qui sera connectée sur vmbr1. En effet, nos VM middle passeront systématiquement par les VM front pour tous les accès réseau.
Ici nous avons une configuration vraiment simplifiée des VM middle. Il faut juste qu'elles puissent joindre les fronts via vmbr1.
On oublie pas de désactiver ipv6 aussi comme pour les fronts.
sudo nano /etc/network/interfaces
Avec de quoi atteindre le réseau public fourni par vmbr0 et le réseau interne fourni par vmbr1 :
# The loopback network interface auto lo iface lo inet loopback # To access vmbr1 for internal network auto eth0 iface eth0 inet static address 192.168.100.21 netmask 255.255.255.0 gateway 192.168.100.11 dns-nameservers 62.210.16.6 62.210.16.7
Note : évidemment sur la 2ème vm middle on change la gateway pour utilisa la seconde vm front et non pas mettre tout sur la première. Cela fonctionnerait puisqu'on a construit un réseau qui permet à toutes les VM de parler ensemble.
Et on reboot (version j'ai la flemme) puis on test.
On oublie pas ensuite une mise à jour du système puisqu'on a le réseau public enfin acessible.
C'est un peu de la répétition mais pour tous vos serveur il peut être utile de configurer les clients ssh pour utiliser votre port personnalisé. Sinon ce sera des commandes ou il faudra préciser toujours le port à la main.
Pour cela on modifie le fichier
sudo nano /etc/ssh/ssh_config
Et on active la ligne (à adapter en fonction de votre configuration) :
Port 2222
Egalement pour simplifier les commandes sur chaque host, je vous conseille de mettre leurs nom avec leur ip sur le réseau interne dans votre fichier hosts.
sudo nano /etc/hosts
A adapter par contre mais c'est pour l'exemple :
# Localhost 127.0.0.1 localhost 127.0.1.1 NOM_MACHINE_LOCALE # Other servers on internal network IP1 NOM_MACHINE_2 IP2 NOM_MACHINE_3
Pour la partie applicative sur nos différentes VM (je rappelle 2 front et deux middle / back) je choisis les éléments suivants :
Nginx en proxy inverse, car j'ai testé varnish mais il est proprio et surtout ne gère pas le SSL ce qui m'a beaucoup embêté (obligé de remettre un nginx devant pour le SSL !!). De plus il semble qu'il n'ait pas du tout à rougir de ses performances d'après ce comparatif.
Nginx en serveur web, car il est plus léger que le vénérable apache.
PHP FPM car je veux que PHP tourne en service standalone et maintenant que ça existe faut pas se priver ! Je n'ai jamais aimé le fait que PHP soit intégré aux serveurs webs.
MySQL rien à dire dessus c'est souvent ce serveur qui est utilisé pour les applications web que j'installe donc bon…
Evidemment cette architecture concerne mes besoins et ma réflexion, elle sera a adapter chez vous je suppose.
Pour cette architecture, j'ai choisi de faire fonctionner nginx en reverse proxy et en serveur web. Il est donc temps de l'installer sur toutes les VM. Comme les packets de ubuntu sont plus que dépassés, on choisit d'installer nginx via les dépots officiels nginx.
Avant tout on récupère la clé gpg :
cd wget http://nginx.org/keys/nginx_signing.key
Et on ajoute cette clé dans apt :
sudo apt-key add nginx_signing.key
Et enfin on ajoute le repo officiel nginx :
sudo nano /etc/apt/sources.list.d/nginx.list
Pour y ajouter (a adapter en fonction de votre distribution) :
# From http://wiki.nginx.org/Install deb http://nginx.org/packages/ubuntu/ trusty nginx deb-src http://nginx.org/packages/ubuntu/ trusty nginx
Et on met a jour les dépots :
sudo apt-get update
Et on installe le paquet (les autres noms de paquets viennent des dépots d'ubuntu et comportent des versions plus vieilles) :
sudo apt-get install nginx
Comme on veut configurer notre NGINX en proxy reverse avec du cache nous retouchons à la configuration. Je me suis basé en partie sur la doc nginx et la doc ubuntu mais attention sur la doc ubuntu : mettre la conf proxy dans un fichier conf à part charge la conf trop tard dans l'ordre des conf et provoque une erreur. La solution est donc de mettre cette partie dans le nginx.conf.
sudo nano /etc/nginx/nginx.conf
Qui devrait ressembler à quelque chose comme ça :
user www-data www-data;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Log configuration
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
# Misc configuration
sendfile off;
keepalive_timeout 65;
#
# Enable gzip compression
# See : http://www.nginxtips.com/how-to-configure-nginx-gzip-compression/
#
gzip on;
gzip_comp_level 6;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 4 32k;
gzip_types text/plain application/x-javascript text/xml text/css;
gzip_vary on;
#
# Set client body size to 5M #
# See : http://www.cyberciti.biz/faq/linux-unix-bsd-nginx-413-request-entity-too-large/
#
client_max_body_size 5M;
# Proxy and cache configuration
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_hide_header X-Powered-By;
proxy_intercept_errors on;
proxy_buffering on;
proxy_cache_key "$scheme://$host$request_uri";
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=cache:10m inactive=7d max_size=700m;
# Include configuration files for differents sites
include /etc/nginx/conf.d/*.conf;
}
Note : L'option sendfile est souvent présentée à on. Cet article explique très bien l'utilité de cette option. Sauf qu'elle pose visiblement souci (pas confirmé mais j'en ai fortement l'impression) pour l'utilisation de liens symboliques. Par exemple sur phpmyadmin on se retrouve a avoir les fonctions jquery désactivées… (ou encore d'autres trucs corrigé autrement mais bon..). Exemple de souci sur cette page
Et enfin nous configurons nos sites (ici je fais celui par defaut mais le travail est le même pour chaque site et à adapter) :
sudo nano /etc/nginx/conf.d/default.conf
Qui va ressembler à quelque chose comme ceci :
server {
listen 80;
server_name localhost;
# Proxy to the backend
location / {
proxy_pass http://192.168.100.21;
# To enable cache : carefull php will be cached too !
# proxy_cache cache;
# proxy_cache_valid 12h;
# expires 12h;
# proxy_cache_use_stale error timeout invalid_header updating;
}
# Cache of static content
location ~*^.+(swf|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
proxy_pass http://192.168.100.21;
proxy_cache cache;
proxy_cache_valid 2d;
expires 7d;
}
}
Evidemment ce sont des conf minimales à perfectionner et a adapter en fonction de ce que vous avez sur vos backends (i.e. sur les middles).
Comme vu plus haut, on part sur une installation de PHP5 FPM sur les middle pour faire tourner nos applis dans un service PHP indépendant. Pour cela on fait simple (enfin ça c'est pour mes besoins, c'est à adapter pour vous) :
sudo apt-get install php5-fpm sudo apt-get install php5-mysql sudo apt-get install php5-cgi sudo apt-get install php5-cli sudo apt-get install php5-curl sudo apt-get install php5-gd sudo apt-get install php5-mcrypt sudo apt-get install phpmyadmin
Voilà les packages installés chez moi :
sudo dpkg --get-selections | grep php
php-gettext install php5-cgi install php5-cli install php5-common install php5-curl install php5-fpm install php5-gd install php5-json install php5-mcrypt install php5-mysql install php5-readline install phpmyadmin install
Un peu de configuration de PHP FPM
sudo nano /etc/php5/fpm/php.ini
Voici les choses à modifier principalement pour la sécurité :
open_basedir = /var/www:/tmp:/usr/share/phpmyadmin:/var/lib/phpmyadmin:/usr/share/javascript disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,exec,system,popen,proc_open,shell_exec
A noter que par défaut php fpm écoutera sur un socket
/var/run/php5-fpm.sock
Mais qu'on peut le faire écouter sur un port particulier. Ici on choisit le sock puisque notre serveur web est sur le middle aussi donc pas besoin de passer par le réseau.
Le détail de cette partie de la conf se situe dans le fichier
sudo nano /etc/php5/fpm/pool.d/www.conf
Enfin, avec la dernière version de PHP, APC semble ne plus fonctionner… C'est remplacé par un module built in comme expliqué sur cette page et cette page
sudo nano /etc/php5/fpm/php.ini
Et modifier ainsi (la taille de mémoire est a adapter en fonction de votre serveur)
opcache.enable=1 opcache.memory_consumption=1024 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60
Et bien sur redémarrer le service :
sudo service php5-fpm restart
Et pour avoir un petit visu sur l'état de votre configuration de cache je vous recommande ce petit outil.
Et pour les optimisations, j'ai cet article me semble très bien (j'y ai trouvé l'outil ci dessus).
Si votre phpmyadmin vous fait un truc dans ce style :
PHP message: PHP Fatal error: require_once(): Failed opening required './libraries/php-gettext/gettext.inc'
Alors la solution se trouve sur cette page.
sudo rm /usr/share/phpmyadmin/libraries/php-gettext/* sudo ln /usr/share/php/php-gettext/* /usr/share/phpmyadmin/libraries/php-gettext
Si votre phpmyadmin rale sur mcrypt :
Cette page pourrait vous aider
sudo php5enmod mcrypt sudo service php5-fpm restart
Pour améliorer vos logs (attention si ya de la charge déjà sur les serv' c'est a éviter) sur php fpm (sinon c'est un peu light comme indiqué sur cette page) :
sudo nano /etc/php5/fpm/pool.d/www.conf
Activer ceci :
catch_workers_output = yes
Ici il s'agit d'installer NGINX sur les VM middle. La procédure est la même que pour les front. Par contre concernant la configuration on n'est plus sur de serveur proxy mais du serveur web classique.
Un exemple de configuration générale :
sudo nano /etc/nginx/nginx.conf
user www-data www-data;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Get real ip from front server
set_real_ip_from 192.168.100.12;
real_ip_header X-Forwarded-For;
# Log configuration
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
# Misc configuration
sendfile on;
keepalive_timeout 65;
#
# Enable gzip compression
# See : http://www.nginxtips.com/how-to-configure-nginx-gzip-compression/
#
gzip on;
gzip_comp_level 6;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 4 32k;
gzip_types text/plain application/x-javascript text/xml text/css;
gzip_vary on;
#
# Set client body size to 5M #
# See : http://www.cyberciti.biz/faq/linux-unix-bsd-nginx-413-request-entity-too-large/
#
client_max_body_size 5M;
# Include configuration files for differents sites
include /etc/nginx/conf.d/*.conf;
}
Il suffira ensuite de le faire communiquer avec PHP FPM via le sock mis en place précédemment.
Par exemple :
sudo nano /etc/nginx/conf.d/default.conf
Donne :
server {
listen 80;
server_name localhost;
#access_log /var/log/nginx/log/localhost.access.log main;
root /var/www/default;
index index.html index.htm index.php;
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
# pass the PHP scripts to FastCGI server
location ~ ^(.+\.php)(/.*)?$ {
fastcgi_pass unix:/var/run/php5-fpm.sock;
include fastcgi_params;
}
# Security deny .ht* files like htaccess
location ~ /\.ht {
deny all;
}
# Rewrites rules
location / {
try_files $uri $uri/ /index.php?$args;
}
}
Note 1 : La partie .ht est pour éviter que des .htaccess et compagnie trainent en visible alors qu'ils ne sont utilisés que par apache et pas par nginx (certaines appli en laissent trainer partout).
Note 2 : La partie rewrite est proposée a titre d'exemple mais est à adapter ou a enlever selon votre application. Elle propose un remplacement des règles de rewrite habituellement vues avec apache.
Installation MySQL, rien de particulier à ajouter.
sudo apt-get install mysql-server
Et une petite correction à faire en se basant sur cet article si vous voyez ce message :
[Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
On corrige donc :
sudo nano /etc/mysql/my.cnf
Et on modifie ceci :
key_buffer = 16M
myisam-recover = BACKUP
Comme ceci (et c'est le premier buffer size si vous en avez plusieurs) :
key_buffer_size = 16M
myisam-recover-options = BACKUP
Sur ubuntu de base il faut passer par une petite phase d'installation.
sudo apt-get install mailutils
Puis pour la configuration voir comme évoqué plus haut.
sudo dpkg-reconfigure postfix
Spécificité pour les middles, comme leurs mails passeront forcément par le front, le nom de courrier doit correspondre au nom de la vm front. Exemple monserveur1.domaine.net si la vm front s'appelle monserveur1 et que vous lui avez bien affecté un dns monserveur1.domaine.net comme vu dans les parties précédentes.
Pas grand chose à ajouter, simplement il ne faut pas oublier. Vous pouvez vous référer aux précédentes parties où j'ai déjà abordé ces sujets.