ElasticSearch sur NAS Synology + Docker

Ce guide va présenter comment configurer ElasticSearch et Kibana sur un NAS Synology avec Docker. Le but n’est pas d’avoir une machine ultra-performante mais de pouvoir avoir une installation ElasticSearch facilement maintenable pour des tests ou juste découvrir l’outil. Il sera ainsi possible de mettre à jour rapidement la version dl’ElasticSearch sans perdre de données grâce à l’utilisation de Docker.

Récupération des images Docker

Récupérer les images elastic/elastic-search et elastic/kibana, ce sont les images officielles. Si vous possédez un Synology équiper d’un processeur 64bit, vous pouvez utiliser l’image amd64.

Création des conteneurs: elasticsearch

Pour créer un conteneur, aller dans Image, sélectionner l’image, puis « Lancer »:

Ensuite, choisir « Paramètres avancés »

Paramètres généraux: choisir le nom du conteneur

Volume: configurez deux dossier, config et data avec accès en écriture. C’est là que seront stockés les configurations ainsi que les données des indexes

Fichier/Dossier: le répertoire sur votre NAS, à définir selon votre structure de répertoire.

Chemin d’accès:

/usr/share/elasticsearch/config

/usr/share/elasticsearch/data

Configurer les ports locaux pour les ports du conteneur 9200 et 9300 du conteneur elasticsearch.

Dans environnement, ajouter le paramètre discovery.type = single-node

Création des conteneurs: kibana

Similaire à elasticsearch:

Pour les ports locaux, attention de bien le spécifier, sans ça, impossible d’accéder à Kibana (port 5601 par défaut)

Configuration elasticsearch et kibana

Dans elasticsearch.yml, activer la sécurité: xpack.security.enabled: true. Pour plus de détail: https://www.elastic.co/guide/en/elasticsearch/reference/7.11/get-started-enable-security.html

redémarrer le conteneur puis, dans le shell, mettre à jour les mots de passe (attention de ne pas les perdre, en particulier celui de kibana_system):
./bin/elasticsearch-setup-passwords interactive

Dans kibana.yml, configurer le mot de passe kibana_system selon ce qui a été défini dans le conteneur elastic. Adapter le port elasticsearch si nécessaire.

Voici le miens:

server.name: kibana
server.host: « 0 »
elasticsearch.username: « kibana_system »
elasticsearch.password: « ********** »
elasticsearch.hosts: [ « http://elasticsearch:9200 » ]
monitoring.ui.container.elasticsearch.enabled: true

Le paramètre elasticsearch.hosts tel que défini nécessite de lier les deux conteneurs:

Démarrer les deux conteneur (vous pouvez lier kibana à elasticsearch pour qu’ils soient démarrés en même temps)

Accéder à l’URL de votre NAS avec le port spécifié pour Kibana, vous devriez avoir la page de login qui s’ouvre, pour ensuite accéder à Kibana.

Catégorie : Coding, ElasticSearch | Tag , , , | Laisser un commentaire

Windows 10: installation de WSL2 et Debian

Le build 19013 de Windows 10 est disponible depuis peu pour les Insider du programme « lent » (ie, qui présente le moins de risques d’instabilité):

Configuration en Insider « Lent »

Concrètement, cela permet d’installer WSL2, disponible depuis le build 18917 : https://docs.microsoft.com/en-us/windows/wsl/wsl2-install

Par la suite, il est possible d’installer différentes distributions Linux: Debian, Ubuntu, Alpine, …

shell debian

A suivre: les premières expériences avec WSL2.

Catégorie : Uncategorized | Tag , , | Commentaires fermés sur Windows 10: installation de WSL2 et Debian

Tensorflow sur Google Colab

En voulant tester quelques bouts de code utilisant Tensorflow, j’ai constaté que mon PC datait un peu: il n’a pas de support CPU supportant les instructions AVX.

Une version « raspberry-pi » existe depuis 2018 mais elle est loin de permettre de travailler efficacement. L’exemple classic sur le dataset MNIST prend en effet un temps assez conséquent à s’exécuter:

import tensorflow as tf
mnist = tf.keras.datasets.mnist

(x_train, y_train),(x_test, y_test) = mnist.load_data()
x_train, x_test = x_train / 255.0, x_test / 255.0

model = tf.keras.models.Sequential([
  tf.keras.layers.Flatten(),
  tf.keras.layers.Dense(512, activation=tf.nn.relu),
  tf.keras.layers.Dropout(0.2),
  tf.keras.layers.Dense(10, activation=tf.nn.softmax)
])
model.compile(optimizer='adam',
              loss='sparse_categorical_crossentropy',
              metrics=['accuracy'])

model.fit(x_train, y_train, epochs=5)
model.evaluate(x_test, y_test)

Le résultat avec le raspberry-pi:

pi@raspberrypi:~/tensorflow $ python3 mninst.py 
Downloading data from ...
11493376/11490434 [===] - 2s 0us/step
Epoch 1/5
60000/60000 [===] - 107s 2ms/step - loss: 0.2007 - acc: 0.9407
Epoch 2/5
60000/60000 [===] - 104s 2ms/step - loss: 0.0797 - acc: 0.9758
Epoch 3/5
60000/60000 [===] - 104s 2ms/step - loss: 0.0515 - acc: 0.9835

...

Soit près de 2ms par step.

Depuis une année, Google propose Colab : https://colab.research.google.com qui permet gratuitement un environnement Jupyter avec tensorflow pré-installé. Il y a même des GPU disposition.

CPU:

Epoch 1/5 
60000/60000 [===] - 17s 289us/sample - loss: 0.2223 - acc: 0.9342
Epoch 2/5
60000/60000 [===] - 17s 281us/sample - loss: 0.0969 - acc: 0.9706
Epoch 3/5
60000/60000 [===] - 17s 282us/sample - loss: 0.0696 - acc: 0.9783
Epoch 4/5
60000/60000 [===] - 17s 286us/sample - loss: 0.0532 - acc: 0.9836
Epoch 5/5
60000/60000 [===] - 18s 301us/sample - loss: 0.0442 - acc: 0.9856
10000/10000 [===] - 1s 64us/sample - loss: 0.0715 - acc: 0.9805
[0.07151023466372862, 0.9805]

GPU:

Epoch 1/5 
60000/60000 [===] - 8s 136us/sample - loss: 0.2170 - acc: 0.9358
Epoch 2/5
60000/60000 [===] - 8s 134us/sample - loss: 0.0954 - acc: 0.9718
Epoch 3/5
60000/60000 [===] - 8s 133us/sample - loss: 0.0690 - acc: 0.9781
Epoch 4/5
60000/60000 [===] - 8s 133us/sample - loss: 0.0530 - acc: 0.9830
Epoch 5/5
60000/60000 [===] - 8s 134us/sample - loss: 0.0442 - acc: 0.9853
10000/10000 [===] - 1s 70us/sample - loss: 0.0609 - acc: 0.9807
[0.06085205714175245, 0.9807]

La version CPU sur Colab est plus de 5x plus rapide que sur un raspberry-pi et la version GPU 10x plus rapide (pour l’exemple ci-dessus).

Il peut donc être intéressant de créer ses modèles sur Colab, à condition d’être conscient que Google y a probablement accès…

Catégorie : Uncategorized | Commentaires fermés sur Tensorflow sur Google Colab

Développement Python sous Gentoo sans perturber l’environnement du système

Sous Gentoo, l’environnement Python est particulièrement sensible car il est utilisé par le gestionnaire de packages: portage.
L’outil pip, également utilisable pour installer des paquets Python risque d’interférer avec l’environnement du système.

Il est parfois nécessaire d’avoir des paquets python qui ne sont pas proposé directement par la distribution Gentoo. Dans cette situation, il est préférable d’utiliser virtualenv.

Cet outil permet d’installer un environnement python complètement séparé de celui du système.

Installation:

emerge virtualenv

mkdir ~/virtualenv/dev
cd ~/virtualenv/dev
virtualenv .

activer l’environnement:

source ./bin/activate

et installer les paquets requis

pip install ....

Catégorie : Uncategorized | Tag , | Commentaires fermés sur Développement Python sous Gentoo sans perturber l’environnement du système

Installation environnement crossdev ARM sur Gentoo (x86 32/64)

Il peut être pratique d’avoir un environnement de développement ARM utilisable directement depuis un environnement x86 lorsqu’on ne possède pas d’environnement dédié (périphérique cible, raspberry PI par exemple) ou qu’on ne veut pas émuler tout un système d’exploitation dans Qemu pour lancer un simple binaire.

Les étapes suivantes décrivent comment installer l’environnement de compilation (GCC) ainsi que les outils permettant d’exécuter directement un binaire ARM.

Lire la suite

Catégorie : ARM, Coding, Gentoo | Tag , , , , , , | Commentaires fermés sur Installation environnement crossdev ARM sur Gentoo (x86 32/64)

Bridge Mode avec modem Thomson de UpcCablecom

Il peut arriver que l’on veuille avoir un accès direct au net sans que le modem fasse office de routeur.

Pour se faire, il suffit d’y accéder en utilisant l’URL locale 192.168.100.1 (login/mot de passe par défaut: <vide>/admin).

Ensuite, dans Gateway -> SwitchMode, choisir ‘Disable mode’ au lieu de Legacy RG IPv4 mode.

source: https://support-en.upc-cablecom.ch/app/answers/detail/a_id/6323/~/bridge-mode-with-the-thomson-wlan-modem

Catégorie : Uncategorized | Tag | Commentaires fermés sur Bridge Mode avec modem Thomson de UpcCablecom

Chasse aux ballons

Vidéo de la partie « chasse aux ballons » durant la Vercorun 2014.

Catégorie : Uncategorized | Commentaires fermés sur Chasse aux ballons

Changer le prefix des tables wordpress

Voici la procédure pour changer le préfix d’une installation WordPress existante (par défaut, il vaut ‘wp_’).

Prenons par exemple, un schema test sur lequel se trouve les tables, et que l’on veut changer le préfix wp_ en monPrefix_,  la requête SQL suivante permet de générer les alters requis:

SELECT CONCAT('RENAME TABLE ', GROUP_CONCAT('`', TABLE_SCHEMA, '`.`', TABLE_NAME, '` TO `', TABLE_SCHEMA, '`.`monPrefix_', SUBSTR(TABLE_NAME,4), '`')) ASFROM `information_schema`.`Tables` WHERE TABLE_SCHEMA='test';

Ensuite, ouvrir wp-config.php et modifier la valeur de la variable : $table_prefix en ‘monPrefix_‘.

On pourrait croire que les étapes ci-dessus sont suffisantes, mais au moment d’accéder à la console d’administration, le message suivant apparaît:

Vous n’avez pas les droits suffisants pour accéder à cette page

Il faut encore modifier les valeurs en base de donnée qui sont basées sur ce préfix :

  • dans la table wp_options, pour la ligne la ligne dont le champ option_name vaut wp_user_roles , il faut le modifier en monPrefix_user_roles
  • de même, dans la table wp_usermeta, il faut changer le prefix de toute les lignes ayant comme valeur de champ meta_key les valeurs suivantes :
    • wp_autosave_draft_ids,
    • wp_capabilities,
    • wp_usersettings,
    • wp_usersettingstime 

    deviennent :

    • monPrefix_autosave_draft_ids,
    • monPrefix_capabilities,
    • monPrefix_usersettings
    • monPrefix_usersettingstime 
Catégorie : Coding, PHP | Tag , | Commentaires fermés sur Changer le prefix des tables wordpress

Pilotes graphiques nvidia-drivers avec noyau 3.6.* sous Gentoo

Voici un problème que j’ai rencontré pour la mise à jour des pilotes graphiques nvidia sous Gentoo avec le noyau 3.6.*:

/var/tmp/portage/x11-drivers/nvidia-drivers-295.71/work/kernel/nv-acpi.c: In function 'nv_acpi_remove':
/var/tmp/portage/x11-drivers/nvidia-drivers-295.71/work/kernel/nv-acpi.c:303:9: error: too many arguments to function 'acpi_os_wait_events_complete'

Lire la suite

Catégorie : Ebuild, Gentoo, Linux | Tag , | Commentaires fermés sur Pilotes graphiques nvidia-drivers avec noyau 3.6.* sous Gentoo

Android sous VirtualBox x86, pour s’éviter les lenteurs de l’émulateur ARM

Voulant tester à nouveau le développement Android, j’ai décidé de ressortir le kit de développement installé sur ma Gentoo.

J’ai remarqué qu’IDEA proposait maintenant un plugin pour le dev android gratuit dans l’édition comunity et j’ai donc profité de l’occasion pour le télécharger en version 11 (ma licence full s’arrêtant à la version 10…).

Par contre, en voulant lancer l’appli générée sur l’émulateur, j’ai constaté que le CPU (du moins 1 coeur de CPU) était pris à 100% et que l’émulateur était plutôt inutilisable (2-3 secondes de réponse pour chaque action telle qu’un click, un caractère entré…). Que ça soit en utilisant l’image ARM ou la x86, le problème persiste.

Utilisation CPU par l'émulateur Android ARMLes explication fournies sur le tracker d’issue Android permettent de gagner un peu en rapidité mais chez moi, l’émulateur met facilement 5 minutes à ce lancer et reste toujours très peu utilisable, même avec ces astuces.

En cherchant un peu, je suis tombé sur un projet permettant de faire fonctionner correctement Android avec une architecture x86 et proposant surtout des images VirtualBox: Buildroid.
Lire la suite

Catégorie : Android, Gentoo, Java | Tag , , , , , , | Commentaires fermés sur Android sous VirtualBox x86, pour s’éviter les lenteurs de l’émulateur ARM