pull/2/head
Yax 3 years ago
parent 0371bdea14
commit 24160cee23

@ -1,15 +1,15 @@
<!-- title: Mes extensions Gnome 40 -->
<!-- category: GNU/Linux -->
La mise à jour récente vers Gnome 40 de ma distribution EndeavourOS m'a amené à faire un tour des extensions Gnome installées pour vérifier qu'elles étaient toujours compatibles et à en découvir des nouvelles. Parce qu'on peut aimer les terminaux mais aussi apprécier les interfaces graphiques bien léchées ;-) Et dans ce domaine, Gnome a atteint l'excellence avec une cohérence d'ensemble qui le rend très agréable à utiliser.
La mise à jour récente vers Gnome 40 de ma distribution EndeavourOS m'a amené à faire un tour des extensions Gnome installées pour vérifier qu'elles étaient toujours compatibles et à en découvrir des nouvelles. Parce qu'on peut aimer les terminaux mais aussi apprécier les interfaces graphiques bien léchées ;-) Et dans ce domaine, Gnome a atteint l'excellence avec une cohérence d'ensemble qui le rend très agréable à utiliser.
Voici donc mes extensions usuelles disponibles sur [le site officiel](https://extensions.gnome.org/).
## Unite
## Unite
Celle extension permet de personnaliser quelques comportements (comme l'emplacement des notifications fugitives), d'améliorer le visuel de la barre principale (mais tout est question de goût personnel) et d'intégrer une systray.
Celle extension permet de personnaliser quelques comportements (comme l'emplacement des notifications fugitives), d'améliorer le visuel de la barre principale (mais tout est question de goût personnel) et d'intégrer une systray.
Voici les réglages possibles :
Voici les réglages possibles :
![reglages unite](/images/2021/unite-settings.png)
@ -19,9 +19,9 @@ Et le résultat :
## Dash to Plank
Plank est un dock qui se place par défaut en bas de l'écran, des raccourcis vers les applications les plus utilisées. Il a la modestie de se cacher lorsqu'une application est plein écran et il réapparait quand le pointeur de souris touche le bord bas de l'écran.
Plank est un dock qui se place par défaut en bas de l'écran, des raccourcis vers les applications les plus utilisées. Il a la modestie de se cacher lorsqu'une application est plein écran et il réapparaît quand le pointeur de souris touche le bord bas de l'écran.
Gnome a aussi un *dock* (mais je ne suis pas sûr qu'ils l'appellent ainsi) sur lequel on peut déposer nos applications favorites et qui apparait quand on appelle les activités.
Gnome a aussi un *dock* (mais je ne suis pas sûr qu'ils l'appellent ainsi) sur lequel on peut déposer nos applications favorites et qui apparaît quand on appelle les activités.
L'idée géniale de cette extension est de lire la configuration Gnome des applications favorites et d'utiliser Plank pour l'afficher.
@ -29,12 +29,7 @@ L'idée géniale de cette extension est de lire la configuration Gnome des appli
## En bonus
J'ai deux autres extensions à l'essai :
J'ai deux autres extensions à l'essai :
- **Gnome 40 UI improvements** : je n'ai pas encore regardé en détail si ces améliorations valent la peine
- **Show Desktop Button** : anti-ergonomique, une icône de maison logéé dans la systray qui minimise toutes les fenêtres ouvertes afin... d'admirer son fond d'écran ;-)
- **Show Desktop Button** : anti-ergonomique, une icône de maison logée dans la systray qui minimise toutes les fenêtres ouvertes afin... d'admirer son fond d'écran ;-)

@ -3,7 +3,7 @@
J'ai utilisé les workflows de Github, appelés *"Github Actions"* pour constuire et publier mes images Docker sur le Docker Hub. Jusqu'à aujourd'hui, c'était un process géré *à la papa* ; j'avais un projet commun avec tous mes docker files, la plupart n'était plus utilisés depuis un bail et je lançais les quelques commandes docker build / tag / push à la demande.
Et puis la finalisation de la version 2.0 de Stacosys qui est une version orientée qualité (suppression de demi-fonctionalités jamais mises en oeuvre, ajout de tests unitaires, simplification de la base de code existante), m'a ramené sur le sujet de la CI/CD complètement laissé de côté dans mes projets perso.
Et puis la finalisation de la version 2.0 de Stacosys qui est une version orientée qualité (suppression de demi-fonctionnalités jamais mises en œuvre, ajout de tests unitaires, simplification de la base de code existante), m'a ramené sur le sujet de la CI/CD complètement laissé de côté dans mes projets perso.
J'ai donc fait la liste des images réellement utilisées dans mon docker-compose :
- les dockerfiles qui correspondent à un projet de dev ont été rapatriés dans le projet Github correspondant,

@ -43,7 +43,7 @@ Le workflow est exécuté à chaque push sur n'importe quelle branche. On défin
- les version de Python : je retiens la première 3.9 (GA) et la dernière mineure de la 3.9
- les versions de Poetry, le système de build : la dernière stable me suffit, ce n'est pas Poetry que je teste.
- les systèmes d'exploitation : le tryptique classique Linux / MacOS / Ms Win
- les systèmes d'exploitation : le triptyque classique Linux / MacOS / Ms Win
A partir de cette matrice, le workflow va calculer le produit cartésien de tous les environnements de tests et dérouler les actions sur chacun. On s'appuie sur l'action poetry du [marketplace Github](https://github.com/marketplace?type=actions) pour avoir un workflow plus concis et plus lisible :

@ -0,0 +1,56 @@
<!-- title: Sécurisation Docker : des pistes -->
<!-- category: Hébergement -->
Je réfléchis à renforcer la sécurité de mon serveur à base de docker compose. J'ai plutôt confiance dans mes containers mais c'est un sentiment subjectif et non justifiable. Certes j'utilise autant que possible des images officielles mais :
- je n'ai aucun outil pour tester les vulnérabilités
- je ne suis pas à l'abri d'une compromission d'un container par l'exploitation d'une faille.
Je m'intéresse à deux aspects de la sécurisation :
1. le réseau : le contrôle des flux intra-containers et des containers vers l'hôte
2. les permissions : tous mes containers s'exécutent actuellement en tant que *root*
Le contrôle du réseau est limité par ce que propose Docker, et plus exactement *docker compose*. J'ai retenu la possibilité de segmenter en plusieurs réseaux et de définir dans quel réseau placer un container avec l'option *-networks*.
Exemple avec le blog et deux réseaux "blog-backend" et "blog-frontend" :
```yaml
version: '3'
services:
stacosys:
container_name: stacosys
image: kianby/stacosys
volumes:
- ${ROOT_INSTALL}/data/stacosys:/config
networks:
- blog-backend
restart: unless-stopped
expose:
- 8100
blog:
container_name: blog
image: kianby/blogduyax
depends_on:
- stacosys
networks:
- blog-backend
- blog-frontend
restart: unless-stopped
expose:
- 80
labels:
- traefik.enable=true
- traefik.http.routers.blog.rule=Host(`${HOST_BLOG}.${DOMAIN}`)
- traefik.http.routers.blog.entrypoints=https
- traefik.http.routers.blog.tls=true
- traefik.docker.network=blog-frontend
```
Placer un container dans deux réseaux lui procure une adresse IP sur chacun et il a, de facto, accès à tous les containers sur ces deux réseaux. Cela permet de ne pas placer un container avec un rôle de *backend* (comme une base de donnée) sur un réseau *frontend* qui est exposé vers l'extérieur (via Traefik). Cela protège un peu plus d'une compromission d'un container mais ce n'est pas extraordinaire car chaque container peut accéder à la machine hôte et à tous les containers des réseaux auxquels il appartient et ceci sans restriction.
Je réfléchis à des moyens d'aller plus loin dans la sécurisation avec des techniques officielles. J'ai lu un cas de mise en oeuvre où on désactive la gestion d'iptables par Docker et on crée ses propres règles pour contrôler tous les échanges. Effectivement c'est efficace mais on perd toute la gestion dynamique des containers et on se retrouve à administrer un pare-feu. Je ne souhaite pas aller dans cette voie.
Pour l'aspect documentation, j'ai utilisé l'outil [Nwdiag](http://blockdiag.com/en/nwdiag/nwdiag-examples.html) pour représenter graphiquement les réseaux qui composent mon déploiement. Les sources sont sur le projet : https://github.com/kianby/selfhosting/
Loading…
Cancel
Save