PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

Miamondo : OFFICE, OUI, MAIS LIBÉRÉ DE WINDOWS !

lundi 12 mars 2018 à 22:24

Un article du collectif Emmabuntüs publié également sur l'âge de faire. Après dix ans d’utilisation de Linux et de la suite bureautique LibreOffice, la municipalité de Munich, qui a basculé des verts à la droite, réinstalle Windows, propriété de Microsoft, ainsi que Microsoft Office sur son parc informatique. Elle remet ainsi en cause des choix... Lire la suite →

Gravatar de Miamondo
Original post of Miamondo.Votez pour ce billet sur Planet Libre.

Pierre-Alain Bandinelli : Utiliser HAProxy pour profiter d'HTTP/2

lundi 12 mars 2018 à 08:00

Les versions 1.8.x d'HAProxy (premier représentant de la branche publié fin 2017) supportent le protocole HTTP/2 pour la communication frontale (section frontend). L'utiliser en amont de votre infrastructure est un moyen facile de rendre ce protocole disponible même si certains de vos serveurs sous-jacents (backend) n'en sont pas encore capables.

Installer HAProxy 1.8.x sur Debian Stretch

La version distribuée officiellement dans Debian Stretch est 1.7.x. Pour installer une version de la branche 1.8.x, il y a au moins 2 alternatives :

  1. compiler l'outil à partir du code source disponible sur le site officiel
  2. utiliser https://haproxy.debian.net/ qui va fournir un dépôt spécifique

Configurer HAProxy

La configuration d'HAProxy se fait par défaut dans /etc/haproxy/haproxy.cfg.

Voici un exemple de fichier de configuration dont les principales sections sont commentées plus bas :

global
	log /dev/log	local0
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin
	stats timeout 30s
	user haproxy
	group haproxy
	daemon

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# Default ciphers offered by Mozilla here:
	#  https://mozilla.github.io/server-side-tls/ssl-config-generator
    ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
    ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

defaults
	log	global
	mode	http
	option	httplog
	option	dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http

frontend http-in
	bind :::80 v4v6

	acl host_letsencrypt path_beg /.well-known/acme-challenge/
	use_backend letsencrypt if host_letsencrypt

	redirect scheme https code 301 if !host_letsencrypt
 
frontend https-in
	bind :::443 v4v6 ssl crt-list /etc/haproxy/crt-list.txt alpn h2,http/1.1
	option forwardfor
	http-request add-header X-Forwarded-Proto https

        # Define hosts
        acl host_alpha hdr_end(host) -i a.fr
	acl host_beta hdr(host) -i precis.b.fr
	acl host_gamma hdr_reg(host) ^d1.c.fr|d2.c.fr$

        # figure out which one to use
        use_backend alpha if host_alpha
	use_backend beta if host_beta
	use_backend gamma if host_gamma

	default_backend iota

backend alpha
        server alpha 192.168.1.1:80

backend beta
        server beta 192.168.1.2:80

backend gamma
        server gamma 192.168.1.3:80

backend iota
        server iota 192.168.1.4:80

backend letsencrypt
        server letsencrypt 192.168.1.1:8080

Quelques commentaires pour bien comprendre...

On écoute d'abord en HTTP (donc sur le port 80, en IPv4 et IPv6) et on redirige tout vers l'HTTPS (redirect scheme https code 301) car c'est une bonne pratique aujourd'hui de n'offrir que du contenu protégé par SSL/TLS.

frontend http-in
	bind :::80 v4v6
	redirect scheme https code 301

Si l'on utilise letsencrypt pour générer ses certificats et qu'ils sont tous générés sur une machine dédiée pour ne pas avoir à se poser de questions sur les différents types de serveurs sous-jacents, on peut rajouter une exception pour les appels utilisés dans l'ACME challenge de letsencrypt et rediriger alors le trafic vers une machine spécifique ici nommée letsencrypt.

frontend http-in
	bind :::80 v4v6

	acl host_letsencrypt path_beg /.well-known/acme-challenge/
	use_backend letsencrypt if host_letsencrypt

	redirect scheme https code 301 if !host_letsencrypt

On écoute bien sûr également sur le port 443 pour gérer les connexions en SSL/TLS :

frontend https-in
	bind :::443 v4v6 ssl crt-list /etc/haproxy/crt-list.txt alpn h2,http/1.1
	option forwardfor
	http-request add-header X-Forwarded-Proto https

Il y a beaucoup de choses intéressantes ici :

On définit ensuite quelques règles ACL pour, selon le nom d'hôte, orienter la connexion vers un backend ou autre. J'ai mis ici plusieurs exemples que j'utilise - il existe des dizaines d'autres filtres y compris sur d'autres critères que le nom d'hôte (on a vu l'URL dans le cas de letsencrypt un peu plus) : filtre sur la fin du nom d'hôte (tout nom d'hôte finissant par a.fr sera redirigé vers le backend alpha), filtre sur le nom d'hôte complet (precis.b.fr sera envoyé vers beta) ou filtre sur le nom d'hôte avec des expressions régulières.

        # Define hosts
        acl host_alpha hdr_end(host) -i a.fr
	acl host_beta hdr(host) -i precis.b.fr
	acl host_gamma hdr_reg(host) ^d1.c.fr|d2.c.fr$

        # figure out which one to use
        use_backend alpha if host_alpha
	use_backend beta if host_beta
	use_backend gamma if host_gamma

On définit également un backend par défaut (iota ici) :

	default_backend iota

Et il reste alors à définir chaque backend :

backend example
        server example 1.2.3.4:80

Pour aller plus loin

Les options possibles dans HAProxy sont fort évidemment beaucoup plus nombreuses ! La documentation est très détaillée et claire ici https://www.haproxy.org/#docs.

Gravatar de Pierre-Alain Bandinelli
Original post of Pierre-Alain Bandinelli.Votez pour ce billet sur Planet Libre.

Ilphrin : Trier les articles Wordpress par une date 'champs personnalisé'

lundi 12 mars 2018 à 05:00

Il vous est surement déjà arrivé, en travaillant sur un thème Wordpress, d’avoir à créer un ‘champ personnalisé’, un champ supplémentaire qui contient une information liée à un article, une catégorie, un tag, ou tout autre entité Wordpress. On peut créer différent type de champ personnalisé, et celui sur lequel on va s’attarder aujourd’hui est le type Date, associé à un article.

Et surtout comment l’utiliser pour trier nos articles.

Un champ personnalisé de Date

Un champ personnalisé est une métadonnée liée à un article, une page, etc. On peut rajouter autant de métadonnées que l’on veut, et celles-ci peuvent contenir une très large gamme d’information: Un chaine de caractère, un nombre, une date, une heure …

On peut voir les champs personnalisés d’un article en déroulant le menu “Options de l’écran” en haut, puis en cochant “Champs Personnalisés”. Vous pouvez maintenant voir en bas de l’article toutes les métadonnées de l’article, et pourrez aussi en rajouter un.

Wordpress theme optionsOptions de l’écran

Pour simplifier l’article j’ai utilisé le plugin Advanced Custom Fields PRO (La version non-PRO est tout aussi bien pour notre cas). Ce plugin permet de créer rapidement des champs pour chaque article sans avoir à rajouter la clé de métadonnée à chaque nouvel article.

Le cas d’utilisation — Créons un Thème

Voici la situation: Vous gérer la création d’un site Wordpress pour un organisme X. X va poster fréquemment des articles concernant des événements Meetup que les employé·e·s organisent. Ces événements ont tous une date à laquelle elles se déroulent. L’objectif est donc d’avoir une page de Blog qui va lister tous les articles, et les trier non pas par date d’écriture de ceux-ci, mais par la date de l’événement auquel chaque article correspond.

Pour cela nous devons partir d’un nouveau thème, car cela va nécessiter d’écrire un peu de code PHP. Je ne vais pas détailler la création d’un thème, il existe suffisamment de documentation sur le sujet.

WP_QUERY pour faire des requêtes

Si vous avez déjà créé un thème par le passé, ou si vous venez de suivre l’un des liens que je viens de vous donner, normalement vous disposez d’un dossier de thème avec un fichier functions.php à la racine. Ce fichier peut contenir tout un tas d’actions à enregistrer avant le chargement d’un page wordpress, ajouter du CSS ou du JavaScript à charger dans votre site ou, dans notre cas, modifier une requête vers le contenu d’une base de données de notre site.

Wordpress dispose d’un objet très puissant qui gère toutes les requêtes, qui s’appelle WP_QUERY. En modifiant directement cet objet, vous allez pouvoir modifier la façon dont Wordpress fait ses requêtes pour aller récupérer vos articles.

Vous avez vos articles, ils sont beaux, bien écrits, et donnent envie d’aller à ces événements. Vous avez même pris le temps d’ajouter un champ personnalisé qui contient la date de votre événement pour chaque article. Ce champ possède la clé: “date_evenement”. Nous allons maintenant aller rajouter une action qui va s’exécuter juste avant d’aller récupérer les articles:

add_action( 'pre_get_posts', 'get_post_by_event'  );
function get_post_by_event( $query  ) {
  if( $query->is_main_query() && !is_admin() && is_home()  ) {
    $query->set( 'meta_key', 'date_evenement'  );
    $query->set( 'orderby', 'meta_value'  );
    $query->set( 'order', 'ASC'  );
  }
}

Voyons pas-à-pas ce que fait ce code:

  1. Tout d’abord nous enregistrons l’action, qui s’appelle pre_get_posts, et nous lui demandons de lancer get_post_by_event au moment adéquat.
  2. La fonction get_post_by_event prend un paramètre $query qui est une instance de la classe WP_QUERY. C’est ce paramètre qui va nous servir pour trier les articles.
  3. Cette condition permet de vérifier que nous traitons la bonne requête, mais aussi de vérifier sur quel page nous nous trouvons. Ces fonctions sont internes à Wordpress.
  4. Nous utilisons 3 fois la méthode set de $query pour modifier la requête. La première détermine une clé de métadonnée pour la requête, ici 'date_evenement'. La deuxième fois nous modifions l’ordre dans lequel les articles seront retournés, par meta_value, c’est-à-dire en fonction de la valeur de la clé de chaque article.

Et enfin nous modifier l’ordre pour qu’on ait les événements du plus récent au plus lointain, mais ceci n’est pas obligatoire.

WP_QUERY et les actions

WP_QUERY est un objet assez complexe à maitriser (je ne prétends pas d’ailleurs le maitriser complétement!), mais une fois qu’on a mis les mains dedans, on se rend compte des nombreuses possibilités qu’il offre. À ma connaissance, c’est aussi personnalisable que si vous pouviez écrire directement la requête SQL qui va chercher les articles.

En combinant cet objet avec les actions de Wordpress, les possibilités deviennent vraiment très nombreuses, et je ne peux que vous inviter à lire la documentation de la liste des actions possible pour vous faire une idée!

Gravatar de Ilphrin
Original post of Ilphrin.Votez pour ce billet sur Planet Libre.

Ilphrin : Trier les articles Wordpress par une date 'champs personnalisé'

lundi 12 mars 2018 à 05:00

Il vous est surement déjà arrivé, en travaillant sur un thème Wordpress, d’avoir à créer un ‘champ personnalisé’, un champ supplémentaire qui contient une information liée à un article, une catégorie, un tag, ou tout autre entité Wordpress. On peut créer différent type de champ personnalisé, et celui sur lequel on va s’attarder aujourd’hui est le type Date, associé à un article.

Et surtout comment l’utiliser pour trier nos articles.

Un champ personnalisé de Date

Un champ personnalisé est une métadonnée liée à un article, une page, etc. On peut rajouter autant de métadonnées que l’on veut, et celles-ci peuvent contenir une très large gamme d’information: Un chaine de caractère, un nombre, une date, une heure …

On peut voir les champs personnalisés d’un article en déroulant le menu “Options de l’écran” en haut, puis en cochant “Champs Personnalisés”. Vous pouvez maintenant voir en bas de l’article toutes les métadonnées de l’article, et pourrez aussi en rajouter un.

Wordpress theme optionsOptions de l’écran

Pour simplifier l’article j’ai utilisé le plugin Advanced Custom Fields PRO (La version non-PRO est tout aussi bien pour notre cas). Ce plugin permet de créer rapidement des champs pour chaque article sans avoir à rajouter la clé de métadonnée à chaque nouvel article.

Le cas d’utilisation — Créons un Thème

Voici la situation: Vous gérer la création d’un site Wordpress pour un organisme X. X va poster fréquemment des articles concernant des événements Meetup que les employé·e·s organisent. Ces événements ont tous une date à laquelle elles se déroulent. L’objectif est donc d’avoir une page de Blog qui va lister tous les articles, et les trier non pas par date d’écriture de ceux-ci, mais par la date de l’événement auquel chaque article correspond.

Pour cela nous devons partir d’un nouveau thème, car cela va nécessiter d’écrire un peu de code PHP. Je ne vais pas détailler la création d’un thème, il existe suffisamment de documentation sur le sujet.

WP_QUERY pour faire des requêtes

Si vous avez déjà créé un thème par le passé, ou si vous venez de suivre l’un des liens que je viens de vous donner, normalement vous disposez d’un dossier de thème avec un fichier functions.php à la racine. Ce fichier peut contenir tout un tas d’actions à enregistrer avant le chargement d’un page wordpress, ajouter du CSS ou du JavaScript à charger dans votre site ou, dans notre cas, modifier une requête vers le contenu d’une base de données de notre site.

Wordpress dispose d’un objet très puissant qui gère toutes les requêtes, qui s’appelle WP_QUERY. En modifiant directement cet objet, vous allez pouvoir modifier la façon dont Wordpress fait ses requêtes pour aller récupérer vos articles.

Vous avez vos articles, ils sont beaux, bien écrits, et donnent envie d’aller à ces événements. Vous avez même pris le temps d’ajouter un champ personnalisé qui contient la date de votre événement pour chaque article. Ce champ possède la clé: “date_evenement”. Nous allons maintenant aller rajouter une action qui va s’exécuter juste avant d’aller récupérer les articles:

add_action( 'pre_get_posts', 'get_post_by_event'  );
function get_post_by_event( $query  ) {
  if( $query->is_main_query() && !is_admin() && is_home()  ) {
    $query->set( 'meta_key', 'date_evenement'  );
    $query->set( 'orderby', 'meta_value'  );
    $query->set( 'order', 'ASC'  );
  }
}

Voyons pas-à-pas ce que fait ce code:

  1. Tout d’abord nous enregistrons l’action, qui s’appelle pre_get_posts, et nous lui demandons de lancer get_post_by_event au moment adéquat.
  2. La fonction get_post_by_event prend un paramètre $query qui est une instance de la classe WP_QUERY. C’est ce paramètre qui va nous servir pour trier les articles.
  3. Cette condition permet de vérifier que nous traitons la bonne requête, mais aussi de vérifier sur quel page nous nous trouvons. Ces fonctions sont internes à Wordpress.
  4. Nous utilisons 3 fois la méthode set de $query pour modifier la requête. La première détermine une clé de métadonnée pour la requête, ici 'date_evenement'. La deuxième fois nous modifions l’ordre dans lequel les articles seront retournés, par meta_value, c’est-à-dire en fonction de la valeur de la clé de chaque article.

Et enfin nous modifier l’ordre pour qu’on ait les événements du plus récent au plus lointain, mais ceci n’est pas obligatoire.

WP_QUERY et les actions

WP_QUERY est un objet assez complexe à maitriser (je ne prétends pas d’ailleurs le maitriser complétement!), mais une fois qu’on a mis les mains dedans, on se rend compte des nombreuses possibilités qu’il offre. À ma connaissance, c’est aussi personnalisable que si vous pouviez écrire directement la requête SQL qui va chercher les articles.

En combinant cet objet avec les actions de Wordpress, les possibilités deviennent vraiment très nombreuses, et je ne peux que vous inviter à lire la documentation de la liste des actions possible pour vous faire une idée!

Gravatar de Ilphrin
Original post of Ilphrin.Votez pour ce billet sur Planet Libre.

Journal du hacker : Liens intéressants Journal du hacker semaine #10

lundi 12 mars 2018 à 00:01

Pour la 10ème semaine de l'année 2018, voici 10 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

Pour ne plus rater aucun article de la communauté francophone, voici :

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Gravatar de Journal du hacker
Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Articles similaires