Cet article de blog deviendra certainement une discussion sur loomio lorsque j’aurais le temps de le traduire. Pour l’instant, l’écrire en Français est plus facile pour moi. Comme mes réflexions peuvent tout de même intéresser (et qu’on peut préférer lire en Français), je les partage ici. Voir aussi cet ancien article sur le même sujet.

Il y a trop de messages dans nos flux

Un réseau social sert majoritairement à partager et à échanger. S’il est correctement utilisé, il peut même permettre une veille efficace et devenir la principale source d’informations. Il suffit pour cela de suivre suffisamment de personnes postant du contenu intéressant. Malheureusement, il peut vite devenir compliqué de faire le tri dans la montagne de messages qui s’entassent dans notre flux. Le nombre de messages qui nous semblent pertinent peut décroître, jusqu’à tomber bien bas, ce qui fait perdre un temps précieux voire nous fait quitter le service.

L’automatisation n’est pas la solution

La solution de Facebook (je ne sais pas pour Twitter, mais j’imagine qu’il y a une pratique similaire) à ce problème consiste à étudier notre usage et notre activité pour filtrer de manière automatique notre flux en nous proposant principalement les personnes et sujets avec lesquels nous interagissons majoritairement. Cette approche pose un problème de cercle vicieux : nous sommes bien évidemment moins susceptible de cliquer sur un contenu qui ne nous est pas présenté, comme nous n’interagissons pas avec lui il nous sera moins souvent présenté, etc. De plus, elle implique de faire de l’analyse des usages et des données, ce que nous essayons de limiter dans le logiciel Libre pour des raisons de respect de la vie privée. À cela, il faut rajouter le fait qu’un ordinateur peut se tromper. Finalement, personne mieux que nous même n’est capable de savoir si un contenu ne nous intéresse ou pas.

Les hashtags, une solution partielle

Nous avons vu que suivre des personnes intéressantes n’est pas une solution suffisante. Ces personnes peuvent parfois poster du contenu qui ne nous intéresse pas. Pire, certaines personnes peuvent parfois poster un contenu qui nous intéresserait, mais poster majoritairement du contenu sans intérêt. Nous pouvons aussi ignorer complètement l’existence d’une personne qui nous intéresserait beaucoup et ne jamais la découvrir. La solution de Twitter et diaspora* à ce problème est le système de hashtag. On peut ainsi se mettre à suivre non pas des personnes mais des sujets, ce qui résout le problème évoqué ci-dessus. Malheureusement, certaines personnes peuvent squatter un hashtag, voir en ajouter systématiquement des dizaines pour tenter de donner de la visibilité à leur message (cas moins régulier sur Twitter où les tweets sont limités à 140 caractères pour le moment). De plus, il est aussi possible d’utiliser un hashtag pour parler de son contraire. Par exemple, une personne postant un article parlant d’un problème sous #windows pourra accompagner son message d’un commentaire comme « Ca ne serait pas arrivé sous #linux ! ». Si nous sommes intéressé par les messages parlant de #linux et donc nous suivons ce hashtag, ce message apparaîtra dans notre flux, alors même qu’il ne parle que du système de Microsoft.

Les expressions booléennes, une suggestion pour diaspora*

Cette idée me trotte dans la tête depuis des années. En fait, je la décris déjà dans la première suggestion de cet article qui date de 2012 ! Il s’agirait de permettre à l’utilisateur d’écrire une requête avec trois entités différentes : les utilisateurs, les aspects et les tags, ainsi qu’avec trois opérateurs (en plus des parenthèses pour déterminer la priorité) : le ou, le et et le non. Un utilisateur pourrait ainsi rechercher #linux && !#microsoft. La réponse à cette requête serait un flux de tous les messages contenant le tag #linux et ne contenant pas le tag #microsoft. Si on se rend compte en plus qu’un utilisateur spamme le tag #linux, on peut aussi l’enlever de ce flux en rajoutant && !@userSpammer. Et voilà, un flux tout propre avec juste ce qui nous intéresse !

Ces requêtes doivent ensuite pouvoir être épinglées pour se retrouver dans la colonne de gauche de la page des flux, afin de pouvoir être sélectionnée facilement sans avoir à réécrire la requête. On pourrait même vouloir lui donner un nom et la définir comme flux par défaut, et, pourquoi pas, combiner les requêtes entre elle toujours avec les trois opérateurs.

Les questions qu’il reste à trancher pour avoir des spécifications complètes :

• # pour les tags et @ pour les personnes sont devenus des standards de fait. Qu’utiliser pour désigner un aspect ?
• &&, || et ! sont bien connus des développeurs. Ce sont cependant des symboles techniques. Doit-on les utiliser ou bien chercher quelque chose d’autres ? Google utilise l’espace pour dire &&, OR pour dire || et – pour dire ! dans sa barre de recherche par exemple.
• Qu’est-ce que vous allez bien pouvoir offrir à Marien et Taratatach pour qu’ils m’aident à implémenter ça ?

Original post of La bande des Geexxx.Votez pour ce billet sur Planet Libre.

Dans un logiciel de retouche photo comme GIMP, les outils de sélection servent surtout à détourer des éléments, c’est-à-dire, à les isoler pour les exporter dans une autre image ou un autre logiciel. GIMP propose plusieurs outils pour détourer et nous pouvons utiliser diverses techniques combinant elles-mêmes plusieurs outils. Dans ce tutoriel nous utilisons l’outil « Extraction de premier plan » (à noter qu’il n’existe pas d’équivalent dans Photoshop).

L’outil « Extraction de premier plan » s’utilise en deux étapes. Vous ne pouvez pas revenir en arrière (annuler la dernière action) tant que vous n’êtes pas arrivé à la fin de la seconde étape. Vous pouvez annuler en cours de route en pressant la touche « Echap » ou en changeant d’outil.

1. définissez votre zone de travail, de manière grossière, autour de l’élément que vous souhaitez détourer. À cette étape l’outil fonctionne comme la sélection à main levée.
2. recouvrez toutes les teintes que vous voulez conserver dans la sélection finale. À présent, l’outil se comporte comme l’outil pinceau. À ceci près que changer la taille de la brosse est moins pratique : elle est constante quelque soit le niveau de zoom, donc, il est conseiller de zoomer ; cela augmente votre précision et a pour effet de rendre la brosse plus petite par rapport à l’image. Passez donc bien sur les teintes que vous voulez garder en évitant soigneusement celle dont vous ne voulez pas. Presser la touche « Ctrl » pour inverser le comportement.

À chaque fois que vous relâchez le bouton de la souris GIMP recalcule la zone choisie. Vous pouvez recommencer la seconde étape autant de fois que vous le souhaitez. À la fin validez en pressent « Entrée ».

La vidéo montre également comment exporter l’image obtenue au format PNG (rappel, le format Jpeg ne gère pas la transparence).

Dans un prochain tutoriel nous verrons comment utiliser le fameux masque de calque qui permet d’obtenir le détourage parfait ! Nous verrons également commet utiliser ce palmier détouré pour l’insérer dans un nouveau décor. Et peut-être même comment le transformer en brosse et créer une forêt de palmiers !

Si vous voulez soutenir l’auteur, l’inciter à publier de nouveaux tutoriels plus rapidement, vous pouvez mettre une pièce dans le jukebox (bouton « Faire un don »). Vous pouvez aussi donner des idées de tutoriels en posant des questions sur comment faire ceci ou cela. Sinon, vous pouvez simplement partager ces vidéos.

Cet article GIMP : détourage par extraction de premier plan est apparu en premier sur Formation logiciel libre.

Original post of Dimitri Robert.Votez pour ce billet sur Planet Libre.

Original post of genma.Votez pour ce billet sur Planet Libre.

Original post of genma.Votez pour ce billet sur Planet Libre.

Rendez-vous à Farpoint

Il y a quelques mois j’entamais une réflexion sur le changement de ma solution d’hébergement. Ce fut le point départ de longues semaines de travail. J’ai parcouru les quatre coins de la toile afin de me documenter sur la mise en place de LXC. Après huit mois de travail le projet commence à se concrétiser. Voici la configuration que j’ai installée afin de réaliser mes essais sur LXC. Mon cahier des charges étant très simple, exécuter mes différents serveurs (mails, dns, web, et autres) dans des containers et en faire une sauvegarde externalisée en cas de pépin. Ce sera l’occasion de faire une petite série d’articles sur mon utilisation de LXC.

Le serveur

Tout d’abord j’ai cherché un nouveau matériel, quelque-chose de peu encombrant, le moins énergivore possible et qui me permettrait de pouvoir exécuter des containers. Actuellement mon serveur hôte datant de 2010 abrite un vieil Athlon II dual-core accompagné de 8Go de ram et d’un disque dur de 500go de disque dur en sata. C’est largement suffisant pour héberger mes quatre containers Openvz et mes deux VM Kvm (qui seront amenées à disparaître avec la nouvelle solution) le tout orchestré par Proxmox. Ma démarche actuelle n’est pas de changer pour plus puissant, je n’utilise même pas la moitié de la RAM et le processeur ne vacille jamais au dessus de 15% d’utilisation. Ce que j’ai mis en place en 2010 n’est plus en adéquation avec ce que  j’aspire aujourd’hui. En effet ce serveur est en configuration moyen tour avec une alimentation de 450 watts et un ventilo de 120mm en façade. Au niveau encombrement il n’est pas facile de lui trouver une place loin du lieu de vie et à cause de sa ventilation vieillissante il a de plus en plus de mal à se faire oublier.
J’ai donc opté pour un petit Brix de chez gigabyte le GB-BXBT-2807. Équipé d’un intel dual-core qui ne consomme que 4w. J’y ai rajouté 8go de ram et un disque-dur de 500Go.  L’encombrement est minimal et je retrouve presque les mêmes performances que mon vieux serveur.

Voici le détail du matériel que j’utilise pour cette configuration :

• BRIX GB-BXBT-2807
• 8 Go de ram Corsair Value Select SO-DIMM 8 Go DDR3L 1333 MHz CL9
• Disque dur Seagate Constellation 500 Go 7200 RPM 64 Mo Serial ATA 6Gb/s

Le choix du disque n’est pas encore arrêté, je me demande si au de niveau bruit il ne vaudrait pas mieux prendre un 5400 tours, mais d’un autre côté j’ai peur de perdre des performances. La vitesse du disque dur est-elle prépondérante dans le fonctionnement des containers ? Je planche encore sur la question. Je commence aussi à regarder du côté des SSD, mais j’avoue que la technologie me fait encore un peu peur.

Mise en place

Le choix du moteur de containers n’a pas était long à prendre, car d’un côté j’avais OpenVZ :

• Vieux noyau
• Incompatible avec systemd donc condamné à utiliser Wheezy
• Silence complet sur le nouveau projet Virtuozzo 7(au moment où j’écris ses lignes)

et de l’autre LXC :

• basé sur les outils noyau donc noyau plus récent
• compatible systemd utilisable sur Jessie et supérieure
• Projet très actif, la dernière mise à jours date de novembre 2015
• Mon goût pour l’aventure, essayé quelque chose de nouveau, bousculer ma routine de geek.

C’est pourquoi j’ai souhaité migrer sous LXC, plutôt que de continuer dans la valeur sûr OpenVZ que j’utilise depuis quelque année déjà.

Pour mon système hôte j’ai donc choisi de partir sur :

• Une Base Debian 8
• Système de fichier BTRFS
• Un point de montage NFS pour les sauvegardes

Voici comment sera organisé mon installation système.

HDD
├── /(/dev/sda1)ext4
│           
├── swap(/dev/sda2)swap
│
└── /lxc-data(/dev/sda4)btrfs
      ├── /var/lib/lxc/(sous-volume0)btrfs
      │       ├── container1
      │       ├── container2
      │       ├── container3
      │       └──....
      │           
      └──/var/lib/lxcsnaps/(sous-volume1)btrfs
              ├── snapshot container1
              ├── snapshot container2
              ├── snapshot container3
              └──....

Dans un premier temps l’intérêt du dispositif LXC+BTRFS réside dans la possibilité de créer très rapidement des instantanés et des clones. Pour les instantanés (snapshot) il faut que le dossier lxcsnaps soit intégré dans le système de fichier btrfs. Les instantanés sont utiles avant une mise à jour système par exemple pour un retour en arrière rapide en cas de problème ou sauvegarder le container en toute simplicité. Le clonage est aussi très intéressant il permet de gagner du temps lors de la création d’un nouveau container. Dans un second temps il s’agit d’une meilleure gestion de l’espace disque lorsque l’on fait plusieurs instantanés d’un même container il ne copie que la partie du conteneur qui a changé. La finalité étant de mettre la partition /var/lib/lxcsnaps sur mon Nas en évitant de sauvegarder les containers sur le serveur.

Pour bénéficier de ce système de fichiers je crée la partition mère lxc-data qui hébergera les différents sous-volumes

mkfs.btrfs /dev/sda4

et de je la monte de façon permanente dans le fstab. Il est recommandé de monter les partitions et sous-volumes btrfs avec l’UUID. Ici l’UUID de sd4 est a69d9182-f4c7-4276-b35d-7d5f9bd50a57.

UUID=a69d9182-f4c7-4276-b35d-7d5f9bd50a57      /lxc-data      Btrfs      rw,noatime,compress=zlib,autodefrag      0      0

Ensuite je crée les deux sous-volumes,

#le sous-volume des containers
btrfs subvolume create lxc
#le sous-volume des instantanés
btrfs subvolume create lxcsnaps

et toujours pour que le montage soit permanent j’ajoute dans le fstab.

UUID=a69d9182-f4c7-4276-b35d-7d5f9bd50a57      /var/lib/lxc      Btrfs      rw,noatime,compress=zlib,autodefrag,subvol=lxc-data/lxc      0      0
UUID=a69d9182-f4c7-4276-b35d-7d5f9bd50a57      /var/lib/lxcsnaps      Btrfs      rw,noatime,compress=zlib,autodefrag,subvol=lxc-data/lxcsnaps      0      0

Voila l’environnement des containers est en place. A voir avec le temps si celui-ci viable pour mon utilisation de LXC, ça tombe bien cela fait parti du test.

Installation et configuration de LXC

Préparation du noyau :

LXC est en perpétuel évolution afin de bénéficier des récents changements, j’utilise un noyau plus récent que celui fournit avec Jessie. J’installe donc celui de la branche testing. Je crée un fichier préférence pour définir la priorité des dépôts :

nano /etc/apt/preferences.d/kernel

Package: *
Pin: release a=stable
Pin-priority: 900
 
Package: *
Pin: release a=testing
Pin-priority: 100
 
Package: linux-image-*
Pin: release a=testing
Pin-priority: 1001
 
Package: linux-headers-*
Pin: release a=testing
Pin-priority: 1001
 
Package: linux-kbuild-*
Pin: release a=testing
Pin-priority: 1001

Ensuite dans le fichier source.list d’apt j’ajoute :

nano /etc/apt/sources.list

# Kernel Testing
deb http://ftp.fr.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.fr.debian.org/debian/ testing main non-free contrib

Pour finir dans mon terminal :

apt update
apt install linux-image-amd64

Après un redémarrage me voilà en version 4.3 du noyau. En revanche, j’ai été obligé de désactiver la mise en veille de l’écran, car celui-ci ne se rallume pas une fois en mode veille.

nano /etc/default/grub
#ajouter consoleblank=0 à la ligne
GRUB_CMDLINE_LINUX_DEFAULT="quiet consoleblank=0"
#reconfiguration de grub
update-grub
#redémarrage du serveur

Installation de LXC sous Debian 8.2 :

apt install lxc bridge-utils libvirt-bin debootstrap cgroupfs-mount

Souhaitant gérer la mémoire et le swap de mes containers je suis obligé d’activer le cgroup responsable de la mémoire qui est déactiver par défaut. Debian a choisi de ne pas activer par défaut ce cgroup afin de ne pas pénaliser les utilisateurs qui ne souhaitent pas les utiliser. Cela évite une trop grande consommation mémoire pour rien. Il me suffit d’ajouter l’instruction “cgroup_enable=memory” et pour le swap “swapaccount=1” au démarrage de Grub.

nano /etc/default/grub
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'
 
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet consoleblank=0 cgroup_enable=memory swapaccount=1"
GRUB_CMDLINE_LINUX=""
[...]

Pour activer les changements sur grub.

update-grub

Pour finir je redémarre mon hôte et vérifie l’installation de LXC

lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.16.0-4-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

Tout est OK, je continue avec la configuration réseau de mon hôte. Pour plus de simplicité la configuration de l’interface réseau de mon hôte sera en mode bridge. L’activation du mode bridge sur le serveur hôte se fait dans le fichier interfaces. Attention toutefois à ce que le paquet bridge-utils soit installé sur l’hôte. Ce fichier régente la configuration des tous les périphériques réseau du système. Il se trouve dans /etc/network/interfaces.

nano /etc/network/interfaces
# je commente les lignes de l'’interface réseau principale 
#allow-hotplug eth0
#iface eth0 inet dhcp

#J'active le bridge avec ip statique sur l’hôte
auto br0
iface br0 inet static
       bridge_ports eth0
       bridge_fd 0
       address < IP de l’hôte ici, exemple: 192.168.1.20>
       netmask 255.255.255.0
       network 
       broadcast 
       gateway 
       dns-nameservers 
       dns-search votre.domaine.de.Recherche.ici

Validation de la modification.

systemctl restart networking

Sur le container qui me servira de base pour cloner les autres, j’applique la configuration réseau suivante.

## Réseau
lxc.utsname = containershostname
lxc.network.type = veth
lxc.network.flags = up

# Ceci est l’interface définit plus haut dans le fichier interface de l’hôte :
lxc.network.link = br0

# Nom de l’interface réseau dans le container,
# lxc.network.name = eth0 

lxc.network.hwaddr = 00:FF:AA:00:00:01

# L’ip du container 
lxc.network.ipv4 = 192.168.1.110/24

# Définissez la passerelle pour avoir un accès à Internet
lxc.network.ipv4.gateway = 192.168.1.1

LXC est maintenant en place, le gros du travail commence. Découvrir l’utilisation des containers, leur configuration, leur sauvegarde et bien d’autre. D’après mes premières manipulations, LXC est aussi facile d’utilisation qu’OpenVz. Il faut que je me familiarise avec les différentes commandes et la philosophie qui ne sont pas les mêmes.  J’ai encore pas mal des questions en suspend, c’est pour cela que je me lance dans ses essais grandeurs natures. Petit à petit je basculerai certains des mes serveurs sur cette nouvelle infrastructure en mode presque réel afin d’observer le comportement de tout ce petit monde. Suite au prochain épisode.

Merci à Deimos et au Wiki Debian qui m’ont beaucoup aider à mettre en place cette plateforme de test.

 

 

Original post of Olivier Delort.Votez pour ce billet sur Planet Libre.