Archives 2018

Le Blog de dada en 2018

Rédigé par dada / 29 décembre 2018 / 5 commentaires

L'année se termine et je me plonge dans Matomo (anciennement Piwik) pour regarder dans le rétro. Je vous propose un rapide tour d'horizon de ce qu'a brassé mon modeste blog ces 12 derniers mois.

Mon Matomo est configuré pour ne pas tracker celles et ceux qui ne le souhaitent pas, d'où l'importance des Inconnus dans les graphiques qui vont suivre.

Les navigateurs

Chrome : 31%

Firefox : 7%

Comme la totalité du Web, je n'échappe pas à l'invasion de Chrome. L'encart publicitaire en haut à droite de la page d'accueil ne fait pas assez effet.

Systèmes d'exploitation

GNU/Linux : 66%

Windows : 16 %

Là, c'est la fête ! Les thèmes abordés dans mes colonnes attirent une population spécifique : l'adepte du logiciel libre ou open source. Ce n'est pas surprenant de voir GNU/Linux en tête des OS chez mes visiteurs. Je me demande quand même où sont passés les utilisateurs de MacOS ?

Périphériques

Bon, là, on se sert des PC pour venir me lire. Les autres machins sont quantité négligeable alors même que PluXml est parfaitement adaptatif et s'affiche très bien sur des petits écrans.

J'ai des infos sur les marques des smartphones : Apple caracole largement en tête, suivi de loin par Samsung.

Les moteurs de recherche

Celui-là, je le mets pour le lol, comme on dit. Google domine.

Les réseaux sociaux

Twitter : 65%

Mastodon : 17%

Facebook : 12%

Je ne sais pas quand Matomo a intégré Mastodon dans sa liste des réseaux sociaux mais c'est une excellente idée ! Twitter domine, c'est clair, mais j'ai maintenant de quoi suivre l'évolution de Mastodon comme vecteur d'information.

Les visites

Classique, tout ça.

Plus de chiffres

Si vous voulez plus de chiffres :

- 1 900 000 visites

- 245 784 000 pages vues

- 34 articles

- 198 commentaires

C'est beau, mais assez faussé. J'ai une armée de lecteurs de flux RSS qui s'amuse à vérifier toutes les 30min si j'ai publié un nouvel article. Je ne sais pas ce que les gens balancent dans leurs lecteurs de flux, mais tout rafraîchir aussi souvent, ça me parait un peu beaucoup.

Enfin voilà. 2018 se termine doucement. Les statistiques m'encouragent encore et toujours à écrire des choses sérieusement. Ne croyez pas que j'écris pour la gloire des chiffres : ils m'intéressent sans plus. J'écris pour partager mes aventures et parfaire mes connaissances. Plus de visiteurs ne me pousse qu'à faire plus attention.

Merci pour cette année 2018 et à 2019 !

Kubernetes en multi-master sur du baremetal avec HAProxy

Rédigé par dada / 20 décembre 2018 / 12 commentaires

Quand on joue avec Kubernetes, on se rend compte que c'est aussi puissant que fragile. L'orchestration, ça ne s'improvise pas. Il faut vraiment passer des heures à se casser les dents sur des clusters de tests qui finiront toujours par s'écrouler. Que ce soit à cause d'un souci côté hébergeur, entraînant une indisponibilité de votre master ou une configuration laxiste permettant à des pods de consommer plus de ressources que ce qu'il y a de disponible, en massacrant chaque node disponible, méticuleusement, les uns après les autres, jusqu'à vous laisser sans rien.

Je ne parlerai pas ici du meilleur moyen pour contrôler la consommation des pods. On va s'attaquer au premier souci : votre unique master configuré en SPoF.

Le multi-master, ton ami

Pour éviter de voir un cluster HS à cause de l'absence de son maître, on va le configurer avec un quorum de... 3 masters. Tout simplement.

Pourquoi HAProxy ?

Mon environnement de test est basé sur des serveurs dans le cloud de Hetzner. J'ai essayé d'attendre aussi longtemps que possible des infrastructures abordables supportant k8s loin des AWS, GCP ou encore Azure, en vain. Il y a bien OVH et DigitalOcean mais le côté "abordable" n'y est pas. Le premier ouvre son infrastructure à partir de 22€ le serveur, et l'autre 20$ (node unique + LB). On est loin des 6€ par machine chez Hetzner.

L'idée

Comme l'indique la documentation officielle, HAProxy va faire ce qu'il sait faire de mieux : rediriger les requêtes. Comment peut-on faire croire à 3 serveurs séparés qu'ils bossent ensemble ? En installant un HAproxy sur chacun d'entre eux, configuré pour loadbalancer les requêtes qui seront balancées sur le 127.0.0.1 et le port 5443 (choisi arbitrairement).

En image, ça donne ça :

Configurés comme ça, nos masters vont s'amuser entre-eux sans aucun souci.

L'installation

Je passe sur la configuration de Kubernetes, j'en parle déjà ici. Notez quand même que vous pouvez suivre ce que je raconte jusqu'à l'init du cluster. Pas plus. Pourquoi ? Parce que sur le premier de vos masters, nous allons ajouter un fichier de configuration :

root@k8smaster1:~# cat kubeadm-config.yaml 
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "127.0.0.1"
controlPlaneEndpoint: "127.0.0.1:5443"
networking:
   podSubnet: "10.244.0.0/16"

Ici, on voit bien que j'ai configuré mon k8s pour taper sur le localhost de la machine à travers le port 5443. C'est là que HAproxy prend la relève.

Je me suis permis d'ajouter la configuration nécessaire à Flannel, mon CNI, qui nécessite en CIDR particulier pour fonctionner correctement. C'est la partie networking.

On peut enchaîner sur la configuration de HAProxy :

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

    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
    ssl-default-bind-options no-sslv3

defaults
    log    global
    mode    tcp
    option    tcplog
    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 api-front
    bind 127.0.0.1:5443
    mode tcp
    option tcplog
    use_backend api-backend

backend api-backend
    mode tcp
    option tcplog
    option tcp-check
    balance roundrobin
    server master1  10.0.42.1:6443 check
    server master2  10.0.42.2:6443 check
    server master3  10.0.42.3:6443 check

La partie global a l'exacte configuration par défaut. J'ai touché à rien.

Dans defaults, j'ai changé le mode de proxy pour le passer de http à tcp.

Les parties frontend et backend regroupent les configurations qui vont bien pour permettre à HAProxy de faire ce que je lui demande. Vous devriez pouvoir recopier tout ça en prenant seulement le soin de changer les IP des masters.

Pour comprendre plus clairement la configuration de HAproxy, je vous redirige vers cet excellent billet de Victor HÉRY.

Une fois configurés, n'oubliez pas de redémarrer les HAProxy sur tous les serveurs et de vérifier qu'ils écoutent bien sur le bon port :

root@k8smaster1:~# nc -v localhost 5443
localhost [127.0.0.1] 5443 (?) open

Astuce : pensez à installer hatop. C'est vraiment super ! Pour le lancer :

hatop -s /var/run/haproxy/admin.sock

Pour le moment, tout sera down, mais une fois le premier master en état, il apparaîtra UP.

On va maintenant initialiser le premier master :

kubeadm init --config=kubeadm-config.yaml

Une fois terminé, vous allez récupérer les informations classiques : le join qui va bien.

kubeadm join 127.0.0.1:5443 --token a1o01x.tokenblabla --discovery-token-ca-cert-hash sha256:blablablablalblawhateverlablablameans --experimental-control-plane

Notez que l'IP de l'API est bien 127.0.0.1 avec le port spécifié à HAProxy. C'est tout bon ! Faites un tour dans hatop et remarquez que le backend du master1 est enfin marqué comme étant UP.

Un get nodes vous confirmera l'arrivée du master1 et un get pods vous montrera les conteneurs de base.

Installons maintenant Flannel, toujours aussi simplement :

kubectl apply -f https://github.com/coreos/flannel/raw/master/Documentation/kube-flannel.yml

Et on aura un premier master en état de fonctionner !

Pour configurer les deux autres masters, il va falloir jouer du SCP. La doc officielle fournit 2 scripts bash que vous pouvez utiliser. Je ne m'étends pas sur le sujet ici et j’enchaîne sur la configuration des autres masters. Pensez quand même à bien configurer SSH et votre user de base.

Une fois que tout est copié, vous n'avez qu'à lancer la commande join sur les masters restant, un par un, et voir le résultat :

dada@k8smaster1:~$ k get nodes
NAME         STATUS   ROLES    AGE   VERSION
k8smaster1   Ready    master   12h   v1.13.1
k8smaster2   Ready    master   11h   v1.13.1
k8smaster3   Ready    master   11h   v1.13.1

Ou encore :

dada@k8smaster1:~$ k get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-86c58d9df4-cx4b7             1/1     Running   0          12h
kube-system   coredns-86c58d9df4-xf8kb             1/1     Running   0          12h
kube-system   etcd-k8smaster1                      1/1     Running   0          12h
kube-system   etcd-k8smaster2                      1/1     Running   0          11h
kube-system   etcd-k8smaster3                      1/1     Running   0          11h
kube-system   kube-apiserver-k8smaster1            1/1     Running   0          12h
kube-system   kube-apiserver-k8smaster2            1/1     Running   0          11h
kube-system   kube-apiserver-k8smaster3            1/1     Running   0          11h
kube-system   kube-controller-manager-k8smaster1   1/1     Running   1          12h
kube-system   kube-controller-manager-k8smaster2   1/1     Running   0          11h
kube-system   kube-controller-manager-k8smaster3   1/1     Running   0          11h
kube-system   kube-flannel-ds-amd64-55p4t          1/1     Running   1          11h
kube-system   kube-flannel-ds-amd64-g7btx          1/1     Running   0          12h
kube-system   kube-flannel-ds-amd64-knjk4          1/1     Running   2          11h
kube-system   kube-proxy-899l8                     1/1     Running   0          12h
kube-system   kube-proxy-djj9x                     1/1     Running   0          11h
kube-system   kube-proxy-tm289                     1/1     Running   0          11h
kube-system   kube-scheduler-k8smaster1            1/1     Running   1          12h
kube-system   kube-scheduler-k8smaster2            1/1     Running   0          11h
kube-system   kube-scheduler-k8smaster3            1/1     Running   0          11h

Un dernier tour sur hatop pour admirer la présence de tous vos backends enfin marqué UP.

Vous avez maintenant un cluster k8s en HA ! La suite serait peut-être de vous raconter comment sortir ETCd du cluster pour le mettre en place dans un cluster séparé dédié, mais non. Ce billet est déjà bien assez long.

Si tout ne se passe pas comme prévu, pensez à regarder la documentation officielle. Mon billet n'est qu'un complément qui peut contenir des coquilles. Pensez aussi à bien vérifier la configuration de votre firewall, ou encore de HAProxy, ou encore de Docker, ou encore votre VPN parce qu'on ne laisse pas tout traîner sur le réseau. Bref.

/e/ sur mon 5T, une semaine plus tard

Rédigé par dada / 03 décembre 2018 / 6 commentaires

Je vais vous étonner. Vraiment. Après une semaine d'utilisation, je peux affirmer que /e/, ça marche.

Si vous avez la bonne idée de me suivre, ici , dans le web 3.0, vous savez que j'ai régulièrement écrit autour de mes aventures avec cette version d'Android un peu spéciale. Je vais y revenir dans ce billet avec plus d'images et des phrases un peu plus longues.

Une version d'Android connectée

Je n'ai jamais lu le site officiel en long, en large et en travers. Jamais. Tout ce que j'ai découvert cette semaine ne provient que de mes tâtonnements. Dans mon précédent billet, je soupçonnais /e/ d'utiliser un Nextcloud pour balancer l'intégralité du contenu important du téléphone dans les nuages. C'est maintenant vérifié. Il suffisait que je me rende sur https://ecloud.global pour le confirmer.

Ça ne saute pas tout de suite aux yeux alors je suis allé voir dans les sources de la page : à l'heure où j'écris ces lignes, Ecloud tourne avec un Nextcloud 14.0.3. Pour info, la dernière version stable de NC est là 14.0.4 et elle est sortie la semaine dernière. Ils ne sont pas encore à jour mais rien d'alarmant.

Voici les données nativement balancées dans l'instance Nextcloud :

On appréciera, ou pas, de voir tout ça partir sur les serveurs de la Fondation, mais c'est là et ça facilitera la vie de celles et ceux qui ne veulent pas maintenir un serveur faisant tourner un Nextcloud.

Autre point important : l'infrastructure utilisée est celle d'OVH, loin des GAFAM. Ça me paraissait évident mais le vérifier rassure toujours.

C'est là, mais pas vraiment

Maintenant que vous savez ce qu'il y a derrière les comptes /e/, je vais vous déconseiller de vous en servir pour le moment. Ça n'est pas à cause des seulement 50 Mo disponibles, c'est parce que la synchro ne semble jamais s’arrêter.

J'étais, depuis quelques heures, loin d'une connexion wifi amicale quand je me suis rendu compte que ma batterie foutait le camp. Si vous avez aussi un téléphone de la marque OnePlus, appréciez cette capture d'écran :

65% de batterie pour moins de 10 heures d'autonomie, on est bien loin des presque 3 nuits et 2 jours d'autonomie observable en temps normal. L'explication ? J'en sais trop rien encore. La synchro semble déconner et passe son temps à uploader des trucs. Comme c'est géré par l'application Nextcloud qu'on sait être ultra gourmande : ça massacre la batterie.

En vrac

- L'alerte sur la consommation de data fonctionne. Ma mésaventure avec mon compte /e/ a fait sonner l'alarme après la disparition de 2 Go de datas dans la nature.

- J'ai découvert que /e/ respectait la configuration par défaut de Silence. Le mode incognito m'a d'abord fait penser à un bug avant qu'on me confirme qu'il s'agit de quelque chose d'absolument normal.

- Je n'ai pas réussi à remettre en place les raccourcis Firefox sur le bureau. J'avais l'habitude d'en faire pour Pixelfed, Peertube et Prismo. L'option est grisée, ce qui me fait penser à un souci de permission.

- Les quelques applications issues du magasin d'application de Google fonctionnent. MicroG s'en sort bien pour moi. En parlant de ça, Aurora Store est vraiment super !

- Le développement est bien actif : on a le droit à 850 Mo d'OTA tous les deux jours, environ. Les changelogs sont disponibles par ici.

- J'ai toujours pas retrouvé comment me servir du lecteur d’empreinte pour scroller. Arg.

Pourquoi ne pas améliorer LineageOS ?

En parlant de /e/ sur Mastodon, je me suis rendu compte qu'il y avait des controverses au sujet de cet OS.

Le grand chef de cette aventure est connu pour avoir créé Mandrake, un fork de Red Hat à l'époque où ce dernier avait une interface franchement Meh. Les plus anciens se souviendront de cette envie qui marqua l'histoire de Linux en France. Il semble à nouveau tenter le coup, avec Android ce coup-ci. Trier ce qu'il y a de primordial pour l’utilisateur, c'est franchement une bonne idée. Les gens ne veulent pas plus savoir comment fonctionnent leur téléphone que leur PC.

Nous savons tous que Ubuntu se base outrageusement sur Debian pour faire son beurre. Il a fallu un peu de temps pour que la valeur ajoutée produite par Ubuntu redescende dans Debian. Ça a coincé un temps, mais c'est bon maintenant. Aussi, plus grand monde ne peste contre Mint qui pompe sur Ubuntu qui pompe sur Debian. Est-ce que /e/ et LineageOS ne pourraient pas se retrouver aussi dans un jeu gagnant-gagnant ? Sans doute que si.

Bref.

Une capture d'écran pour la fin ?

MariaDB en Master/Slave via ProxySQL

Rédigé par dada / 01 décembre 2018 / Aucun commentaire

On y est. J'ai enfin réussi à faire tourner ProxySQL comme je l'entendais pour que mes conteneurs tapent dans des BDD loin de Kubernetes. Sortir ses bases de données du cluster est un choix. Si vous êtes courageux, vous pouvez les laisser dedans. Ceci-dit, faut être un tantinet croyant pour se lancer dans la seconde solution. Dans ces histoires de hautes dispo et de résistance aux pannes, la bonne solution semble être de gérer son cluster de BDD en dehors de son cluster k8s.

Installation des MariaDB

Là, je devrais vous passer une pile de commandes pour installer des serveurs MariaDB en master/slave, mais bon. Tout est très clair dans la documentation officielle.

Sachez simplement que le master porte l'IP 192.168.0.17 et que le slave, lui, là 192.168.0.77.

Installation de ProxySQL

Helm ? Non, pas ici. On va donc pondre un YAML avec le Deployment et le Service qui va bien :

dada@master:~/proxysql$ cat proxysql.yaml

apiVersion: v1
kind: Deployment
metadata:
  name: proxysql
  labels:
    app: proxysql
spec:
  replicas: 2
  selector:
    matchLabels:
      app: proxysql
      tier: frontend
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: proxysql
        tier: frontend
    spec:
      restartPolicy: Always
      containers:
      - image: severalnines/proxysql:1.4.12
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        ports:
        - containerPort: 6033
          name: proxysql-mysql
        - containerPort: 6032
          name: proxysql-admin
      volumes:
      - name: proxysql-config
        configMap:
          name: proxysql-configmap
---
apiVersion: v1
kind: Service
metadata:
  name: proxysql
  labels:
    app: proxysql
    tier: frontend
spec:
  type: NodePort
  ports:
  - nodePort: 30033
    port: 6033
    name: proxysql-mysql
  - nodePort: 30032
    port: 6032
    name: proxysql-admin
  selector:
    app: proxysql
    tier: frontend

A remarquer

Le Deployment contient la configuration de ce qu'on appelle un ReplicatSet. Ça permet à k8s de toujours maintenir le nombre de pods déclaré en fonction. Quand un pod se casse la figure, il revient à lui. Dans un RS, quand un pod de casse la figure, il va aussi revenir à lui. Super. Sauf que, par exemple, dans le cas d'une mise à jour, k8s ne va pas terminer les pods d'un coup, mais les gérer un par un.

Le YAML contient aussi un Service de type NodePort qui va nous permettre de mapper les ports 30032 et 30033 internes aux pods sur les ports 6032 et 6033 accessibles depuis l'extérieur. Voyez la suite du billet pour découvrir qu'au lieu de taper sur le port 3306 de vos serveurs MariaDB, vous allez taper sur le port 6033.

On fait gober tout ça au cluster :

dada@master:~/proxysql$ kubectl apply -f proxysql.yaml

Et voilà le travail :

dada@master:~/proxysql$ kubectl get pods --all-namespaces  | grep proxysql
default            proxysql-5c47fb85fb-fdh4g                              1/1     Running     1          39h
default            proxysql-5c47fb85fb-kvdfv                              1/1     Running     1          39h

Configuration de ProxySQL

Tout va se jouer dans le fichier proxysql.cnf. Tout, ou presque, mais j'en parlerai après. Voici déjà de quoi faire :

datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="proxysql-admin:adminpwd"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}
mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server_msec=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpwd"
}
mysql_replication_hostgroups =
(
        { writer_hostgroup=10, reader_hostgroup=20, comment="MariaDB Replication" }
)
mysql_servers =
(
        { address="192.168.0.17", port=3306, hostgroup=10, max_connections=100, max_replication_lag = 5 },
        { address="192.168.0.77", port=3306, hostgroup=20, max_connections=100, max_replication_lag = 5}
)
mysql_users =
(
        { username = "nextcloud" , password = "nextcloudpwd" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }
)

Il est long alors on va le découper ensemble.

Global

{
        admin_credentials="proxysql-admin:adminpwd"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}

Ici, on retrouve surtout les accès administrateur de ProxySQL et son port qui écoute sans limite d'IP.

Mysql_variables

mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server_msec=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpwd"
}

Là encore, je ne vais pas m'étendre sur toute la configuration (par défaut) mais sur deux points seulement : le port 6033 sera celui que vous allez rentrer dans les fichiers de configuration de vos services ayant besoin de MariaDB et l'utilisateur "monitor" est là pour vérifier l'état de vos serveurs MariaDB.

Mysql_replication_hostgroups

mysql_replication_hostgroups =
(
        { writer_hostgroup=10, reader_hostgroup=20, comment="MariaDB Replication" }
)

C'est à partir de là qu'on commence à s'amuser ! Ici, on déclare deux groupes de serveurs avec deux ID différents. Les writer, ceux qui ont le droit d'écrire et les reader, ceux qui n'auront que le droit de lire. Ça tombe bien, c'est plus ou moins ce qu'on veut.

Mysql_servers

mysql_servers =
(
        { address="192.168.0.17", port=3306, hostgroup=10, max_connections=100, max_replication_lag = 5 },
        { address="192.168.0.77", port=3306, hostgroup=20, max_connections=100, max_replication_lag = 5}
)

Si vous aviez suivi le blabla précédent, vous pouvez déchiffrer ces deux lignes en :

- Le serveur avec l'IP 192.168.0.17 fait partie du groupe des writers On lui demande de traiter 100 connexions actives maximum et d'avoir un lag avec son master de moins de 5 secondes.

- Le serveur avec l'IP 192.168.0.77 fait partie du groupe des reader. On lui demande de traiter 100 connexions actives maximum et d'avoir un lag avec son master de moins de 5 secondes.

Mysql_users

mysql_users =
(
        { username = "nextcloud" , password = "nextcloudpwd" , default_hostgroup = 10 , active = 1 }
)

Les utilisateurs MariaDB doivent être renseignés ici !

Dans mon cas, profitez de la configuration sécurisée de mon utilisateur nextcloud. Il sera assigné à un groupe d'utilisateur par défaut : le groupe des writer, et sera activé. Il est possible qu'un besoin particulier soit à l'origine de la création de la variable "active" mais j'ai du mal à comprendre pourquoi un compte MariaDB resterait renseigné avec active = 0 plutôt que dégagé. M'enfin.

Mysql_query_rules

mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }

Là, c'est la définition des règles qui seront automatiquement appliquées pour chaque serveur. La plus claire est la règle à l'ID 200 qui est assignée au hostgroup 20, celui des reader. C'est là que ProxySQL va faire un tri. Le hostgroup 20 n'ayant que la possibilité de faire des SELECT, on comprend bien qu'on parle de lecteurs uniquement.

ConfigMap

On charge tout ça dans une ConfigMap :

dada@master:~/proxysql$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf

Si on prend le temps de revenir sur le YAML pour comprendre la ConfigMap, on la repère ici :

      containers:
[...]
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
[...]
      volumes:
      - name: proxysql-config
        configMap:
          name: proxysql-configmap

On comprend que les pods ProxySQL vont aller parcourir la liste des ConfigMaps disponibles pour repérer celle qui porte le nom "proxysql-config" et la monter dans /etc/proxysql.cnf.

Vérifier tout le système

Une commande que vous devriez connaître par cœur va nous prouver que tout fonctionne :

dada@master:~/proxysql$ kubectl logs proxysql-5c47fb85fb-fdh4g

Chez moi, elle sort quelque chose comme ça :

2018-12-01 08:30:19 [INFO] Dumping mysql_servers
+--------------+--------------+------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+-----------------+
| hostgroup_id | hostname     | port | weight | status | compression | max_connections | max_replication_lag | use_ssl | max_latency_ms | comment | mem_pointer     |
+--------------+--------------+------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+-----------------+
| 10           | 192.168.0.17 | 3306 | 1      | 0      | 0           | 100             | 5                   | 0       | 0              |         | 140637072236416 |
| 20           | 192.168.0.17 | 3306 | 1      | 0      | 0           | 100             | 5                   | 0       | 0              |         | 140637022769408 |
| 20           | 192.168.0.77 | 3306 | 1      | 0      | 0           | 100             | 5                   | 0       | 0              |         | 140637085320960 |
+--------------+--------------+------+--------+--------+-------------+-----------------+---------------------+---------+----------------+---------+-----------------+

On y retrouve la liste des serveurs et leurs rôles : mon master appartient aux groupes reader et writer. Normal puisqu'il doit écrire et lire. Mon slave, lui, n'appartient qu'au groupe des reader, comme convenu.

Le piège

Si j'ai pesté un certain temps contre ProxySQL sur Mastodon , c'est que ma configuration ne marchait pas alors que tout semblait normal. J'avais bien en tête ce que je viens de vous expliquer: Les reader, les writer, la configuration des users, etc. C'était clair.

Pourtant, quand je lancais mon conteneur Nextcloud pour qu'il s'installe comme un grand, il pété ma réplication en écrivant sur mon slave. Le con.

J'ai fini par ouvrir une issue pour crier à l'aide et on m'a expliqué ceci : ProxySQL vérifie la présence de la variable READ_ONLY sur tous les serveurs renseignés dans la rubrique mysql_replication_hostsgroups. Si la variable est a OFF sur votre slave, la réplication entre les deux serveurs MariaDB ne bronchera pas, mais ProxySQL ira taper dans votre slave, peu importe la configuration en place. Re le con.

Pour vous épargner des soucis, pensez bien à vérifier que votre slave affiche bien ceci :

MariaDB [(none)]> SHOW VARIABLES like 'read_only';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | ON   |
+---------------+-------+
1 row in set (0.00 sec)

Vous êtes bons. Vous pouvez maintenant aller configurer vos pods pour aller taper sur vos MariaDB via proxysql:6033 en place et lieu de localhost:3306.

Retours sur /e/ dans un OnePlus 5T

Rédigé par dada / 26 novembre 2018 / 16 commentaires

C'est donc un dimanche soir, vers 18h, que j'ai décidé de faire ce que j'avais quasiment juré d'arrêter : changer l'OS de mon téléphone.

Je fais partie de celles et ceux qui se sont jetés sur FirefoxOS en y croyant, puis sur Ubuntu Touch, en y croyant déjà moins. L'expérience des abandons et des échecs m'avait pourtant bien fait comprendre que les OS alternatifs sur un objet aussi important que le mobile étaient une mauvaise idée. Et pourtant. Merci Monseigneur.

/e/ ?

Ne me demandez pas comment ça se prononce. Pas la moindre idée. C'est pourtant un OS alternatif basé sur Android dont on entend souvent parler sur Mastodon. N'essayez pas de retrouver le hashtag qui va bien, le nom de l'OS ne permet pas d'en faire une pub correcte. C'est le compte de Gaël Duval qu'il faut suivre pour se tenir informé.

Pour plus d'informations, je vous redirige vers le site officiel de la fondation derrière ce projet. Il faut simplement retenir que l'OS se veut respectueux de la vie privée : ciao les Google Apps, Services et autres cochonneries installées de force dans votre mobile.

/e/ est un projet à but non lucratif, dans l’intérêt de tous. Nous concevons des systèmes d’exploitation mobile open source et des services en lignes associés, qui respectent la vie privée et les données personnelles de chacun.
Nous sommes une équipe internationale d’entrepreneurs expérimentés, de développeurs et de designers, qui s’appuie sur une communauté de contributeurs grandissante.

À quoi ça ressemble ?

Pas grand-chose à raconter. C'est une version propre d'Android avec un thème et un jeu d'icônes personnalisés.

Les applications par défaut

On retrouve les grands classiques bien connus des libristes :

K9Mail pour gérer les mails
Signal et Telegram pour les SMS & co
Chrome (Chromium ?) comme navigateur par défaut
Davdroid pour gérer les carnets d'adresses distants
Etar pour le calendrier
Notes pour la prise de notes
Tasks comme gestionnaire de tâches
Magic Earth pour le GPS
Nextcloud comme gestionnaire de fichiers
Open Camera pour la photo

Personnellement, je ne comprends pas le choix de Chromium. Je reste un adorateur de Mozilla, avec tous les travers que cela entraîne.

Leur navigateur vient avec une configuration particulière : il a pour moteur de recherche par défaut l'instance Searx de la /e/ Foundation.

Sous le capot

Sous le capot, on retrouve une version 8.1.0 d'Android avec les correctifs de sécurité datés du 5 novembre. En passant par la page d'installation de l'OS, on remarque que c'est effectivement une version de LineageOS remastérisée à la sauce /e/. Mastodon me raconte qu'un OS débarrassé des services Google et avec des services de synchronisation, ça existait : CyanogenMod.

Des services ?

Un mail

Si vous en faites la demande, ça n'a rien d'obligatoire, vous pouvez demander la création d'un compte en @e.email. Ce faisant, vous obtiendrez une nouvelle adresse à ajouter entre celle qui sert pour le boulot, la Gmail à spam et la Protonmail qui va bien. Une fois le compte créé, c'est sur un Rainloop que vous allez atterrir.

Sauvegarde des comptes et fichiers

J'ai l'impression qu'ils ont une instance Nextcloud sur leurs serveurs. La liste des applications permet de ne pas trop en douter. C'est une solution simple et bien supportée pour synchroniser tout le contenu important d'un téléphone moderne.

Le magasin d'applications

Là, j'ai un peu froncé les sourcils : il n'y a pas de store par défaut. Si vous en voulez un, c'est à vous d'aller le choper en passant par le navigateur. C'est une manipulation marrante : lancer le navigateur pour aller taper sur une instance Searx et enfin télécharger, disons, F-droid, c'est un truc qu'on ne fait pas souvent.

F-droid

Une fois installé à la main, F-droid ne pose pas de problème. Tout roule. J'ai installé une version complète de Nextcloud, Fennec (Firefox), Maps, Silence pour mes SMS et Tusky.

Aurora Store

C'est encore sur Mastodon qu'on m'a conseillé ce store. Aurora est un fork de Yalp. Il permet d'aller récupérer sereinement vos applications uniquement disponibles sur le Play Store de Google. J'ai réussi à installer mes applications critiques : ProtonMail, ProtonVPN, les applications SNCF et celle de ma banque. Et ça marche. Au choix, vous pouvez vous connecter avec votre compte Google pour retrouver les applications que vous auriez achetées ou passer par leur service anonyme.

Des soucis ?

À l'installation de Tusky, le navigateur qui vient avec /e/ ne m'a pas permis d'autoriser la connexion à mon instance. J'ai dû installer Fennec depuis F-droid et le configurer comme navigateur par défaut pour y arriver.

Autant j'ai réussi à installer des applications du Play Store depuis Aurora sans problème et réussir à m'en servir, autant l'application Qobuz s'est lamentablement vautrée. Rien à faire, elle ne démarre pas. Moi qui envisageais de m'y abonner pour de bon, c'est mal barré. C'est corrigé.

Est-ce que c'est vraiment utilisable ?

OnePlus 5T

Pour le moment, pas grand-chose à signaler. /e/ fonctionne et permet de renouer avec un Android propre. Mon téléphone supporte bien la chose. Même le lecteur d'empreinte fonctionne. J'aimerais bien réussir à le configurer non pas pour qu'il lise le bout de mes doigts mais pour m'en servir comme pavé tactile. Je n'ai pas encore retrouvé l'option.

Au niveau de l'appareil photo, chose pour laquelle j'avais décidé d'acheter un OnePlus 5T, je doute qu'on retrouve le même niveau de qualité que sur OxygenOS. Par exemple, je ne retrouve pas la possibilité de passer par le zoom optique du deuxième capteur. Après, je ne m'en sers jamais. Quant à l'application Open Camera, elle semble quand même fournir une foule d'options intéressantes. N'oubliez pas d'aller régler la résolution à fond dans les options si vous vous voulez retrouver quelque chose qui se rapproche de ce que vous aviez avant.

En général

Avant de vous lancer dans l'aventure, n'oubliez pas que l'absence de Play Store va vous pénaliser d'une façon ou d'une autre. L’intégration de MicroG permet de vivoter mais n'apporte pas de miracle. Les applications sont de plus en plus dépendantes des services Google pour fonctionner. Google a réussi son coup : les développeurs ne regardent même plus ce qu'il y a dans leur SDK et ajoutent des dépendances dégueulasses à la truelle.

Gardez aussi à l'esprit que c'est un OS en version alpha, à utiliser à vos risques et périls.

Je me souviens de l'époque de FirefoxOS : nous étions beaucoup à avoir spécialement acheté les téléphones siglés pour pouvoir nous en servir. J'avais spécialement commandé le téléphone de référence des développeurs, le Flame, pour en avoir un peu plus sous le capot. Certains avaient même pris de leur temps pour aller en faire la promotion dans des grandes surfaces. Une période assez dingue quand on y repense. Le choix de /e/ loin des délires de Mozilla me rassure, un peu. La suite ? On verra.

Liens utiles :

page 1 sur 7 suivante »

Fil RSS des articles