Pour supprimer un Query String avec une Rewrite Rule : <https://www.philipphoffmann.de/blog/2012/08/16/how-to-discard-the-query-string-in-a-rewriterule-apache-mod_rewrite/>
L'indispensable **apachetop** permet de surveiller en direct l'activité d'Apache via un fichier d'access_log (format *combined*) :
~~~{.bash}
~~~
$ apachetop -f access.log -T 3600 -q
~~~
On peut alors visualiser les URLs les plus sollicitées (querystrings inclus grâce à l'option *-q*), et switcher à l'aide de la touche **d** pour voir les adresses IP source ; à l'aide de la touche **n** pour voir la répartition en codes HTTP 2xx/3xx/4xx/5xx.
On peut alors visualiser les URLs les plus sollicitées (querystrings inclus grâce à l'option *-q*), et switcher à l'aide de la touche **d** pour voir les adresses IP source ; à l'aide de la touche **n** pour voir la répartition en codes HTTP 2xx/3xx/4xx/5xx.
Voici l'ensemble des commandes disponibles :
@ -578,7 +578,7 @@ Ajouter `Indexes` dans `AllowOverride`.
### Autorisation Options via .htaccess ?
Si l'on modifie l'option `php_admin_value memory_limit` : un _reload_/_graceful_ suffit pour prendre en compte la modification.
Si l'on modifie l'option `php_admin_value memory_limit` : un _reload_/_graceful_ suffit pour prendre en compte la modification.
Quand on utilise l'authentification LDAP avec un serveur en local, il faut démarrer **slapd** avant de démarrer Apache, sinon celui-ci se plaint qu'il ne peut pas contacter le serveur LDAP, et bloque l'accès aux pages … (erreur 500).
Pour cela, dans le script d'init d'apache2 ajouter slapd dans la directive `Required-Start:`
Pour cela, dans le script d'init d'apache2 ajouter slapd dans la directive `Required-Start:`
$ curl -s -X PUT "127.0.0.1:9200/_snapshot/foo/h${date}?wait_for_completion=true" -o /tmp/es_snapshot_h${date}.log
@ -351,7 +351,7 @@ Nous allons utiliser une base de données d'exemple pour faire des tests.
Télécharger, <https://github.com/andrewvc/ee-datasets/archive/master.zip>, décompresser l'archive et exécuter le programme Java qui va injecter la BDD "movie_db" dans votre cluster ES.
@ -38,7 +38,7 @@ Pour chaque commande, une page de manuel *git-<commande>* est disponible. Par ex
### Créer un dépôt
~~~{.bash}
~~~
$ mkdir foo
$ cd foo
$ git init
@ -48,7 +48,7 @@ $ git init
Plusieurs méthodes d'accès pour récupérer un dépôt : ssh://, http(s)://, git://, file:// etc.
~~~{.bash}
~~~
$ git clone ssh://git.example.com/path/projet.git
$ git clone https://git.example.com/path/projet
$ git clone git://git.example.com/path/projet.git
@ -59,7 +59,7 @@ $ git clone file:///path/projet
Ajouter un nouveau fichier :
~~~{.bash}
~~~
$ touch main.c
$ git add main.c
$ git commit -v
@ -67,7 +67,7 @@ $ git commit -v
Modification d'un fichier existant :
~~~{.bash}
~~~
$ vi main.c
$ git add main.c
$ git commit -v
@ -78,14 +78,14 @@ $ git commit -v
Voir l'état du dépôt local (fichiers non commités, etc.) :
~~~{.bash}
~~~
$ git status
$ git status -s -b
~~~
Voir les derniers commits du dépôt local :
~~~{.bash}
~~~
$ git log
~~~
@ -95,7 +95,7 @@ Si l'on a cloné un dépôt existant, un lien est automatiquement créé entre l
Pour récupérer en local les derniers changements du dépôt distant :
~~~{.bash}
~~~
$ git pull --rebase origin
~~~
@ -103,7 +103,7 @@ $ git pull --rebase origin
Pour envoyer ses modifications locales vers le dépôt référencé comme distant :
~~~{.bash}
~~~
$ git push origin
~~~
@ -115,40 +115,40 @@ garder en tête que c'est une convention, rien n'oblige à en avoir une.
Lister les branches existantes et connaître sa branche courante :
~~~{.bash}
~~~
$ git branch -a
~~~
Passer d'une branche à une autre dans son dépôt local :
~~~{.bash}
~~~
$ git checkout myfeature
$ git checkout master
~~~
Créer une branche *myfeature* à partir de la branche *master* :
~~~{.bash}
~~~
$ git checkout master
$ git branch myfeature master
~~~
Travailler sur la branche *myfeature* puis [merger](#git-merge) son travail dans la branche *master* :
~~~{.bash}
~~~
$ git checkout master
$ git merge --no-ff myfeature
~~~
Pousser une branche locale vers le dépôt référencé comme distant :
~~~{.bash}
~~~
$ git push origin myfeature
~~~
Supprimer une branche locale et distante :
~~~{.bash}
~~~
$ git branch -d myfeature
$ git push origin :myfeature
~~~
@ -159,7 +159,7 @@ $ git push origin :myfeature
Affichage de l'historique de différentes façons :
~~~{.bash}
~~~
$ git log
$ git log -p
$ git log --stat
@ -178,26 +178,26 @@ On peut notamment combiner toutes ces options dans un alias à mettre dans `.git
On peut aussi utiliser *whatchanged* qui va lister tout ce qui a changé :
~~~{.bash}
~~~
$ git whatchanged
$ git whatchanged -p
~~~
Voir l'avant-dernier commit :
~~~{.bash}
~~~
$ git show HEAD~1
~~~
Voir le fichier *foo/bar* tel qu'il était dans l'avant-dernier commit :
~~~{.bash}
~~~
$ git show HEAD~1:foo/bar
~~~
Pour voir ce qu'il s'est passé entre deux commits :
~~~{.bash}
~~~
$ git show HEAD~8..HEAD
$ git show -p HEAD~8..HEAD
~~~
@ -216,13 +216,13 @@ $ gitk --all
Modifier son dernier message de commit :
~~~{.bash}
~~~
$ git commit --amend
~~~
Modifier son dernier commit :
~~~{.bash}
~~~
$ vi main.c
$ git add main.c
$ git commit --amend
@ -230,7 +230,7 @@ $ git commit --amend
Modifier son avant-dernier commit :
~~~{.bash}
~~~
$ git rebase -i HEAD^^
… remplacer « pick » par « edit » pour le commit à modifier
$ vi main.c
@ -247,7 +247,7 @@ $ git rebase --continue
Récupérer un commit d'une autre branche dans master :
~~~{.bash}
~~~
$ git checkout master
$ git cherry-pick <SHA1ducommit>
~~~
@ -274,14 +274,14 @@ foo/bar*
Cela permet d'avoir un buffer pour mettre « en pause » des modifications non commitées :
~~~{.bash}
~~~
…hack…hack…
$ git stash save
~~~
On peut lister ce buffer :
~~~{.bash}
~~~
$ git stash list
stash@{0}: WIP on dev: fb1fa70… m
stash@{1}: WIP on dev: fb1fa70… m
@ -289,13 +289,13 @@ stash@{1}: WIP on dev: fb1fa70… m
Et ré-appliquer la dernière modification stockée :
~~~{.bash}
~~~
$ git stash pop
~~~
Pour purger le buffer sans l'appliquer :
~~~{.bash}
~~~
$ git stash clear
~~~
@ -305,19 +305,19 @@ $ git stash clear
Voir les modifications locales non commitées et non indexés :
~~~{.bash}
~~~
$ git diff
~~~
Voir les modifications locales *suivies* (ajoutées avec *git add*) :
~~~{.bash}
~~~
$ git diff --cached
~~~
Voir les modifications entre deux commits, ou entre deux branches :
~~~{.bash}
~~~
$ git diff HEAD^ HEAD
$ git diff HEAD~8 HEAD^^
$ git diff myfeature master
@ -327,13 +327,13 @@ $ git diff myfeature master
Voir les modifications entre deux commits, mais uniquement pour un fichier *foo* :
~~~{.bash}
~~~
$ git diff HEAD~8..HEAD^^ -- foo
~~~
Avoir un diff inversé (pratique pour faire préparer un revert partiel par exemple) :
~~~{.bash}
~~~
$ git diff -R
~~~
@ -353,25 +353,25 @@ Dans certains cas il est pratique de faire un simple `git fetch`, notamment si l
Pousser toutes ses branches d'un coup (ce qui est déconseillé en général) :
~~~{.bash}
~~~
$ git push --all origin
~~~
Si l'on a une branche locale nommée *foo* et que l'on veut la pousser dans la branche nommée *bar* du dépôt distant :
~~~{.bash}
~~~
$ git push origin foo:bar
~~~
/!\\ Attention, il ne faut jamais modifier un historique qui a été pushé vers un dépôt partagé. Néanmoins dans certaines situations exceptionnelles (un mot de passe ou un email qui aurait été mis par erreur) on peut être amené à faire un `push --force` :
~~~{.bash}
~~~
$ git push -f origin
~~~
Il faudra ensuite que chaque utilisateur du dépôt soit prévenu et accepte d'écraser leur dépôt local (en faisant ou vérifiant les modifications d'historiques) :
~~~{.bash}
~~~
$ git fetch
$ git reset origin
~~~
@ -382,25 +382,25 @@ $ git reset origin
Pour avoir le dépôt tel qu'il était à un commit :
~~~{.bash}
~~~
$ git checkout <SHA1ducommit>
~~~
Pour se remettre sur la version courante :
~~~{.bash}
~~~
$ git checkout master
~~~
Pour créer une branche et switcher directement dans cette nouvelle branche, on utilise l'option `-b` :
~~~{.bash}
~~~
$ git checkout -b myfeature
~~~
Pour annuler toutes les modifications d'un fichier foo/ non indexé :
~~~{.bash}
~~~
$ git checkout foo/
~~~
@ -411,19 +411,19 @@ $ git checkout foo/
Une branche est en fait la création une déviation, un commit qui a deux *enfants*.
On peut ainsi créer une branche à partir de n'importe quel commit :
Pour transmettre ses 3 derniers commits, on peut générer 3 patches qui contiendront les diffs ainsi que les messages de commit :
~~~{.bash}
~~~
$ git format-patch -3
~~~
Si l'on a ces 3 patches, on peut les appliquer sur son dépôt local ainsi :
~~~{.bash}
~~~
$ git am 000*.patch
~~~
@ -545,7 +545,7 @@ Un dépôt classique possède un répertoire `.git/` qui contient toutes les don
Quand on crée un dépôt ayant vocation à servir de dépôt central, il est préférable de ne pas avoir de *working copy* : il s'agira alors d'un **bare repository** que l'on peut initier avec la commande :
Pour générer une clé privée non chiffrée (private.key) et sa demande de certificat associé (demande.csr) à transmettre à une autorité de certification :
Pour s'assurer qu'un certificat est bien issu d'un clé privée, ou d'une demande de certificat (.csr), on peut vérifier la correspondance grâce au *modulus* que l'on peut extraire et comparer :
Puis, interroger le serveur OCSP obtenu (ici http://ocsp.example.com) avec la chaîne de certification (chainfile.pem) et le certificat (certificat.crt) à vérifier :
Pour un service en HTTPS avec l'option SNI qui permet d'envoyer un nom de domaine au sein du protocole SSL/TLS (supporté par 99.9% des navigateurs récents) :
La faille FREAK (Factoring RSA Export Keys) est une vulnérabilité dans OpenSSL permettant une attaque *man-in-the-middle* pour renégocier
La faille FREAK (Factoring RSA Export Keys) est une vulnérabilité dans OpenSSL permettant une attaque *man-in-the-middle* pour renégocier
un chiffrement faible. Cela se base sur des chiffrements « EXPORT » introduits dans les années 2000 par les USA pour pouvoir déchiffrement les communications. Voir <http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html>, <https://freakattack.com/#sysadmin> et <https://www.smacktls.com/>.
On peut tester si un serveur accepte les chiffrements EXPORT avec la commande suivante :
Si on obtient *error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:749* c'est que le serveur n'accepte pas les chiffrements EXPORT.
Si on obtient *error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:749* c'est que le serveur n'accepte pas les chiffrements EXPORT.
Debian [a corrigé cette faille en janvier2015](https://security-tracker.debian.org/tracker/CVE-2015-0204), ce qui est surtout important pour les clients (navigateurs, etc.). On peut vérifier que sa machine ne tolère pas de chiffrements « EXPORT » via la commande `openssl ciphers | tr -s ':' '\n' | sort | grep EXP`. Sous Debian, par défaut Apache et Nginx n'ont pas été impactés car leur liste de chiffrement n'incluait pas EXPORT.
Tout comme screen, Tmux permet de gérer des terminaux lancés en arrière plan. Il s'agit d'une alternative enrichie qui prend notamment en charge des splits plus complexes.
Tout comme screen, Tmux permet de gérer des terminaux lancés en arrière plan. Il s'agit d'une alternative enrichie qui prend notamment en charge des splits plus complexes.
Il diffère de screen avec le concept de fenêtres et "panes". Un "pane" tmux est une fenêtre dans la terminologie de screen. Une fenêtre tmux est un agencement d'un ou plusieurs "pane(s)" (par exemple, deux fenêtres côte à côte).
D'autres points de comparaison :
D'autres points de comparaison :
- les fenêtres sont des entités indépendantes qui peuvent être attachées simultanément à plusieurs sessions et peuvent être déplacées librement entre les sessions d'un même serveur tmux
- plusieurs buffers
@ -18,7 +18,7 @@ D'autres points de comparaison :
## Installation
~~~{.bash}
~~~
# apt install tmux
~~~
@ -34,25 +34,25 @@ travail: 1 windows (created Fri Oct 21 16:05:10 2016) [315x78]
Pour lancer une nouvelle session :
~~~{.bash}
~~~
$ tmux
~~~
Pour lancer une nouvelle session sous le nom test:
~~~{.bash}
~~~
$ tmux new -s test
~~~
Pour lancer une nouvelle session avec mutt par exemple :
~~~{.bash}
~~~
$ tmux new mutt
~~~
Pour se rattacher à la session tmux 1 (voir tmux ls) :
~~~{.bash}
~~~
$ tmux attach -t 1
~~~
@ -67,7 +67,7 @@ Une fois attaché à une session tmux, voici la liste des commandes de base util
On peut aussi purger avec une requête HTTP **PURGE** :
~~~{.bash}
~~~
$ curl -X PURGE http://www.example.org/foo.txt
~~~
@ -516,7 +516,7 @@ sub vcl_recv {
}
~~~
Pour finir, quelques informations sur le load-balancing avec Varnish
Pour finir, quelques informations sur le load-balancing avec Varnish
* Gestion d'un poids pour chaque backend ? Oui, depuis Varnish 2.1.4 on peut préciser des poids pour chaque backend.
* Gestion du maximum de connexions pour un backend ? via le paramètre *.max_connections*
@ -547,7 +547,7 @@ Note : le *saint mode* (qui permet de laisser tranquille pendant un temps défin
### Nagios
On peut se servir du retour de la commande *varnishadm* pour s'assurer du bon état de santé du démon. Ce plugin Nagios utilise ce principe : <http://exchange.nagios.org/directory/Plugins/Websites%2C-Forms-and-Transactions/check_varnish_health/details>.
On peut se servir du retour de la commande *varnishadm* pour s'assurer du bon état de santé du démon. Ce plugin Nagios utilise ce principe : <http://exchange.nagios.org/directory/Plugins/Websites%2C-Forms-and-Transactions/check_varnish_health/details>.
### Munin
@ -568,7 +568,7 @@ On peut se servir du retour de la commande *varnishadm* pour s'assurer du bon é
### Exemple pour Wordpress
Voici un exemple de règles pour un site utilisant WordPress :
Voici un exemple de règles pour un site utilisant WordPress :
~~~
backend default {
@ -735,5 +735,4 @@ Un reload ne suffit parfois pas, un restart sera nécessaire dans certains cas.
### Temps d'attente du client HTTP ?
Quand un client HTTP interroge Varnish, il va le mettre en attente afin d'interroger le serveur HTTP final (si l'objet n'est pas caché). Pendant que le serveur HTTP final renvoie l'objet demandé à Varnish, le client HTTP est toujours mis en attente, le contenu lui sera renvoyé seulement une fois l'objet reçu à 100% par Varnish. Cela peut poser différents problèmes : dans le cas d'une grosse vidéo le démarrage sera lent, si le timeout du client HTTP est bas il peut fermer la connexion trop tôt, etc. Pour contourner ce problème, on peut utiliser le return *(pipe)*.
Quand un client HTTP interroge Varnish, il va le mettre en attente afin d'interroger le serveur HTTP final (si l'objet n'est pas caché). Pendant que le serveur HTTP final renvoie l'objet demandé à Varnish, le client HTTP est toujours mis en attente, le contenu lui sera renvoyé seulement une fois l'objet reçu à 100% par Varnish. Cela peut poser différents problèmes : dans le cas d'une grosse vidéo le démarrage sera lent, si le timeout du client HTTP est bas il peut fermer la connexion trop tôt, etc. Pour contourner ce problème, on peut utiliser le return *(pipe)*.
