Ams-Exploit - Historique des versions

Admin : /* les fichiers du NAS */

2012-10-24T09:11:28Z

les fichiers du NAS

← Version précédente		Version du 24 octobre 2012 à 09:11
Ligne 44 :		Ligne 44 :
	Tout les jours à 3h30 on récupère le contenu de /var/www/upload dans /home/backup/. Toutes les semaines (le Lundi à 4h ) on archive une version.		Tout les jours à 3h30 on récupère le contenu de /var/www/upload dans /home/backup/. Toutes les semaines (le Lundi à 4h ) on archive une version.

−	~~mkdir /home/backup/front/~~	+	dans /etc/cron.d/rsnapshot
−	~~cat~~ /etc/cron.d/rsnapshot	+
−	~~# This is a sample cron file for rsnapshot.~~	+
−	~~# The values used correspond to the examples in /etc/rsnapshot.conf.~~	+
−	~~# There you can also set the backup points and many other things.~~	+
−	#	+
−	~~# To activate this cron file you have to uncomment the lines below.~~	+
−	~~# Feel free to adapt it to your needs.~~	+

	30 3 * * * root /usr/bin/rsnapshot -c /etc/rsnapshot-front.conf daily		30 3 * * * root /usr/bin/rsnapshot -c /etc/rsnapshot-front.conf daily
Ligne 70 :		Ligne 63 :
	└── www		└── www
	└── upload		└── upload
−

	== les bases de données ==		== les bases de données ==

Admin : /* les sauvegardes */

2012-10-24T08:56:39Z

les sauvegardes

← Version précédente		Version du 24 octobre 2012 à 08:56
Ligne 41 :		Ligne 41 :

	= les sauvegardes =		= les sauvegardes =
		+	== les fichiers du NAS ==
		+	Tout les jours à 3h30 on récupère le contenu de /var/www/upload dans /home/backup/. Toutes les semaines (le Lundi à 4h ) on archive une version.
		+
		+	mkdir /home/backup/front/
		+	cat /etc/cron.d/rsnapshot
		+	# This is a sample cron file for rsnapshot.
		+	# The values used correspond to the examples in /etc/rsnapshot.conf.
		+	# There you can also set the backup points and many other things.
		+	#
		+	# To activate this cron file you have to uncomment the lines below.
		+	# Feel free to adapt it to your needs.
		+
		+	30 3 * * * root /usr/bin/rsnapshot -c /etc/rsnapshot-front.conf daily
		+	0 4 * * 1 root /usr/bin/rsnapshot -c /etc/rsnapshot-front.conf weekly
		+
		+
		+	Ainsi les archives sont consultables dans /home/backup/ et s'ordonnent ainsi :
		+
		+	tree /home/backup/
		+	.
		+	└── front
		+	├── daily.0
		+	│ └── var
		+	│ └── www
		+	│ └── upload
		+	└── daily.1
		+	└── var
		+	└── www
		+	└── upload
		+
		+
	== les bases de données ==		== les bases de données ==
	===== les sauvegardes base par base =====		===== les sauvegardes base par base =====
Ligne 49 :		Ligne 80 :
	===== une sauvegarde complète est effectuée sur db02 toutes les 2 heures aussi cf 'crontab -l' =====		===== une sauvegarde complète est effectuée sur db02 toutes les 2 heures aussi cf 'crontab -l' =====
	===== une autre est faite sur db01 dans /home/dump-all.sql =====		===== une autre est faite sur db01 dans /home/dump-all.sql =====
−

	= La synchro d'une mise à jour ou d'un projet vers les frontaux =		= La synchro d'une mise à jour ou d'un projet vers les frontaux =

Admin : /* Load Balancing */

2012-10-22T14:57:05Z

Load Balancing

← Version précédente		Version du 22 octobre 2012 à 14:57
Ligne 102 :		Ligne 102 :

	Un mail est envoyé par le service keepalive lors de la perte et de la récupération de l'un des services apache.		Un mail est envoyé par le service keepalive lors de la perte et de la récupération de l'un des services apache.
		+
		+
		+	=== désactiver un frontal du Load Balancing ===
		+
		+	Le moyen le plus propre pour sortir un service apache du LB est de suprimer le fichier de test. Ainsi le connexion en cours se terminent et le apache n'en reçoit plus. On peut ensuite le couper.
		+	mv /var/www/index.html /var/www/index_save.html
		+	attendre qques secondes et couper le service.
		+	service apache2 stop
		+
		+	Pour le remettre, en production bien penser à remettre le fichier index.html en place.
		+
		+	Un mail est envoyé par keepalive pour annoncé la perte d'un service apache.

Admin : /* l'ajout d'un projet GIT sur la machine d'admin */

2012-10-22T14:50:16Z

l'ajout d'un projet GIT sur la machine d'admin

← Version précédente		Version du 22 octobre 2012 à 14:50
Ligne 57 :		Ligne 57 :

	par exemple :		par exemple :
		+	cd /home/git
	git clone ssh://user@94.23.222.225/home/git/repositories/skiVoiturage.git		git clone ssh://user@94.23.222.225/home/git/repositories/skiVoiturage.git
	cd skiVoiturage/		cd skiVoiturage/

Admin : /* ajouter un vhost pour les frontaux */

2012-10-22T14:46:11Z

ajouter un vhost pour les frontaux

← Version précédente		Version du 22 octobre 2012 à 14:46
Ligne 13 :		Ligne 13 :

	Le plus simple est de copier un vhost existant.		Le plus simple est de copier un vhost existant.
		+	sudo su -
		+	(password user)
	cd /home/config/front/etc/apache2/sites-available		cd /home/config/front/etc/apache2/sites-available
	cp skivoiturage.com.conf newvhost.conf		cp skivoiturage.com.conf newvhost.conf
Ligne 32 :		Ligne 34 :

	Si les DNS pointent bien sur la VIP ( 87.98.251.179 ) alors le site est en ligne.		Si les DNS pointent bien sur la VIP ( 87.98.251.179 ) alors le site est en ligne.
−

	= créer une base de données et les utilisateurs =		= créer une base de données et les utilisateurs =

Admin : /* Se connecter sur la machine d'admin */

2012-10-22T14:43:46Z

Se connecter sur la machine d'admin

← Version précédente		Version du 22 octobre 2012 à 14:43
Ligne 2 :		Ligne 2 :
	admin.prod.allmyski.info		admin.prod.allmyski.info

−	les Utilisateurs sont de la forme initale du prénom Nom (Julien Dupond => jdupond ). Il sont dans le group "ams"	+	les Utilisateurs sont de la forme initale du prénom Nom (Julien Dupond => jdupond ). Ils sont dans le group "ams"
	useradd -m -G ams USER -m		useradd -m -G ams USER -m
	passwd USER		passwd USER
Ligne 9 :		Ligne 9 :

	Ils ont accès via sudo à toutes les commandes. Le groupe ams à tout les droits.		Ils ont accès via sudo à toutes les commandes. Le groupe ams à tout les droits.
−

	= ajouter un vhost pour les frontaux =		= ajouter un vhost pour les frontaux =

Admin : /* Load Balancing */

2012-10-22T14:40:30Z

Load Balancing

← Version précédente		Version du 22 octobre 2012 à 14:40
Ligne 100 :		Ligne 100 :
	LA VIP NE SERA PAS DÉPLACÉE pour la perte d'un serveur apache, cela prend trop de temps (environ une minute) et n'est pas utile. On ne déplacera la VIP qu'en cas de perte de connexion (réseau ou test de vie keepalive) sur le front01 .		LA VIP NE SERA PAS DÉPLACÉE pour la perte d'un serveur apache, cela prend trop de temps (environ une minute) et n'est pas utile. On ne déplacera la VIP qu'en cas de perte de connexion (réseau ou test de vie keepalive) sur le front01 .

−	Un mail est envoyé par le service keepalive ~~de chacune des machines~~ lors de la perte et de la récupération de ~~chacun~~ des ~~frontaux configurés~~.	+	Un mail est envoyé par le service keepalive lors de la perte et de la récupération de l'un des services apache.

Admin : /* Load Balancing */

2012-10-22T14:37:52Z

Load Balancing

← Version précédente		Version du 22 octobre 2012 à 14:37
Ligne 91 :		Ligne 91 :

	=== Load Balancing ===		=== Load Balancing ===
−	Keepalive gère les configurations de ipvs qui permet de faire le routage des paquets vers les ~~serveurs apache~~ de chacune des machines.	+	Keepalive gère les configurations de ipvs qui permet de faire le routage des paquets vers les services Apache de chacune des machines.

	- Chacun des frontaux prend autant de requêtes		- Chacun des frontaux prend autant de requêtes

Admin : /* Principe de fonctionnement du Load Balancing */

2012-10-22T14:36:31Z

Principe de fonctionnement du Load Balancing

← Version précédente		Version du 22 octobre 2012 à 14:36
Ligne 81 :		Ligne 81 :
	Une VIP est l'adresse de front qui peut se déplacer d'un frontal à l'autre. (IP FailOver OVH)		Une VIP est l'adresse de front qui peut se déplacer d'un frontal à l'autre. (IP FailOver OVH)

−	la VIP est associée à l'une des machines par défaut et en fonctionnement nominal elle est configurée sur le serveur front01.	+	la VIP 87.98.251.179 est associée à l'une des machines par défaut et en fonctionnement nominal elle est configurée sur le serveur front01.

	== Keepalive ==		== Keepalive ==
	=== gestion de la VIP ===		=== gestion de la VIP ===
−	Le service keepalive est démarré sur les 2 machines qui se ~~surveille~~ ainsi l'une et l'autre. C'est ce service qui pilote le déplacement de la VIP en cas de panne du front01. Le front02 va la récupérer et savoir répartir la charge ou servir les pages en cas de perte totale de front01. Quand front01 est de nouveau opérationnel, front02 se déconfigure et front01 récupère la VIP.	+	Le service keepalive est démarré sur les 2 machines qui se surveillent ainsi l'une et l'autre. C'est ce service qui pilote le déplacement de la VIP en cas de panne du front01. Le front02 va la récupérer et savoir répartir la charge ou servir les pages en cas de perte totale de front01. Quand front01 est de nouveau opérationnel, front02 se déconfigure et front01 récupère la VIP.

−	Des mails ~~de OVH~~ sont envoyés ~~à chacune de ces opérations~~ de déplacement de VIP.	+	Des mails sont envoyés par OVH (l'adresse contact tech et contact ????) pour chaque opération de déplacement de VIP.

Admin : /* Load Balancing */

2012-10-22T14:30:56Z

Load Balancing

← Version précédente		Version du 22 octobre 2012 à 14:30
Ligne 99 :		Ligne 99 :

	LA VIP NE SERA PAS DÉPLACÉE pour la perte d'un serveur apache, cela prend trop de temps (environ une minute) et n'est pas utile. On ne déplacera la VIP qu'en cas de perte de connexion (réseau ou test de vie keepalive) sur le front01 .		LA VIP NE SERA PAS DÉPLACÉE pour la perte d'un serveur apache, cela prend trop de temps (environ une minute) et n'est pas utile. On ne déplacera la VIP qu'en cas de perte de connexion (réseau ou test de vie keepalive) sur le front01 .
		+
		+	Un mail est envoyé par le service keepalive de chacune des machines lors de la perte et de la récupération de chacun des frontaux configurés.