Récupération d'articles d'archives
This commit is contained in:
@@ -0,0 +1,68 @@
|
||||
---
|
||||
comments_url: https://com.richard-dern.fr/post/545
|
||||
date: '2016-02-14 16:24:26'
|
||||
links:
|
||||
- lang: fr
|
||||
name: Page d'origine sur LinuxFr
|
||||
url: https://linuxfr.org/users/richarddern/journaux/pourquoi-je-suis-passe-a-let-s-encrypt
|
||||
tags:
|
||||
- Let's Encrypt
|
||||
- Certificat
|
||||
title: Pourquoi je suis passé à Let's Encrypt
|
||||
weather:
|
||||
humidity: 85
|
||||
illuminance: 11276.300000000001
|
||||
precipitations: false
|
||||
pressure: 991.2
|
||||
source:
|
||||
- open-meteo
|
||||
temperature: 5.4
|
||||
wind_direction: 263
|
||||
wind_speed: 15.2
|
||||
---
|
||||
|
||||
> La façon dont on gère les certificats à l'heure actuelle me pose problème.
|
||||
> Le principe même de devoir recourir à une instance étrangère pour vérifier l'identité d'un serveur présente, selon moi, un risque pour l'indépendance des éditeurs.
|
||||
> Pourtant, je suis passé sur Let's Encrypt.
|
||||
|
||||
Il y a quelques jours, [je vous parlais des certificats](https://www.athaliasoft.com/a-propos-des-certificats), et notamment de [Let's Encrypt](https://letsencrypt.org/).
|
||||
|
||||
Pour moi, laisser un organisme tiers décider de la validité d'un certificat revient à abandonner notre indépendance.
|
||||
En effet, si nous avons la possibilité de générer des certificats auto-signés, c'est pour _pouvoir_ le faire.
|
||||
Si on peut le faire, faisons-le !
|
||||
|
||||
En re-publiant cet article sur [LinuxFr.org](https://linuxfr.org/users/richarddern/journaux/a-propos-des-certificats), je me suis attiré les foudres de ses lecteurs.
|
||||
Cet échange, bien que houleux et m'ayant laissé un goût amer, m'a fait réfléchir à ce qui était le plus important.
|
||||
|
||||
Par ailleurs, certains éléments d'actualité me conduisent également à réfléchir différemment.
|
||||
Notamment le cas de Google, qui, dans GMail, va [afficher une alerte pour les mails envoyés sans chiffrement](http://www.nextinpact.com/news/98453-gmail-va-afficher-alerte-pour-emails-envoyes-sans-chiffrement-tls-dkim-et-spf.htm).
|
||||
|
||||
Bien que l'initiative de Google soit louable, je doute de son intérêt pour les utilisateurs du service.
|
||||
À moins d'être technicien, à quoi bon avertir l'utilisateur que son correspondant utilise un serveur qui ne met pas en œuvre TLS (ou SPF/DKIM) ?
|
||||
La seule chose que cela va provoquer chez l'utilisateur non technicien, c'est la peur.
|
||||
|
||||
D'autre part, ma réelle inquiétude est de savoir jusqu'où Google compte aller.
|
||||
Il n'y a qu'un pas à franchir entre afficher une alerte parce que le serveur du correspondant n'utilise pas du tout TLS, et parce qu'il utilise un certificat auto-signé.
|
||||
Surtout qu'en tant qu'entreprise influente, les concurrents pourraient suivre.
|
||||
Je fais un raccourci, mais ça signifierait la mort des serveurs mails auto-hébergés ne souhaitant pas utiliser un service comme Let's Encrypt.
|
||||
|
||||
Oui, c'est une niche, les serveurs mails auto-hébergés utilisant un certificat auto-signé.
|
||||
Mais ils existent, et sont là parce que c'est ça Internet: la liberté pour chacun de faire ce qu'il veut de son informatique.
|
||||
|
||||
Or, Google, comme à son habitude, augmente la portée de son droit de vie et de mort sur les petits acteurs insignifiants du net.
|
||||
Mais on s'éloigne quelque peu du sujet.
|
||||
|
||||
Suite à cette annonce, et suite à mon billet sur LinuxFr, j'ai décidé de passer à Let's Encrypt, et du même coup mettre de côté mes principes.
|
||||
La question est: pourquoi ?
|
||||
|
||||
Parce que j'écris pour que mon contenu soit lu, qu'on soit d'accord avec moi ou non.
|
||||
Mon objectif est de faire réfléchir.
|
||||
C'est mon utilité sur Internet.
|
||||
Peut être taper à côté sur le plan technique, mais initier une réflexion, encourager à ne pas faire tout et n'importe quoi parce que Google/Apple/facebook dit que c'est comme ça que les choses doivent être faites.
|
||||
|
||||
Par conséquent, afin que mes visiteurs ne soient pas dérangés par l'alerte relative au certificat auto-signé (et non invalide), je suis passé sur un certificat Let's Encrypt.
|
||||
Parce qu'à défaut de m'en passer, je prends ce qu'il y a de moins pire (je sais, encore une remarque qui me vaudra des insultes, peu importe).
|
||||
|
||||
Par extension, c'est également ce que j'ai fais sur mon serveur mail, afin de prévenir d'éventuels blocages le jour où les serveurs de mes correspondants décideraient de bloquer les certificats auto-signés.
|
||||
|
||||
J'espère simplement qu'un jour, on se rendra compte que pendant des années on a accusé des entreprises comme Google de s'arroger un pouvoir qu'elles n'ont pas à détenir, puis leur donner ce pouvoir parce qu'on a cru ça bon pour le grand public, avant de finalement revenir à un Internet plus authentique et proche de ses valeurs initiales.
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
comments_url: https://com.richard-dern.fr/post/546
|
||||
date: '2016-02-17 02:51:26'
|
||||
links:
|
||||
- lang: fr
|
||||
name: Page d'origine sur LinuxFr
|
||||
url: https://linuxfr.org/users/richarddern/journaux/un-outil-pour-gerer-une-blacklist-dns
|
||||
tags:
|
||||
- Blacklist
|
||||
- DNS
|
||||
title: Un outil pour gérer une blacklist DNS
|
||||
weather:
|
||||
humidity: 84
|
||||
illuminance: 0.0
|
||||
precipitations: false
|
||||
pressure: 1023.7
|
||||
source:
|
||||
- open-meteo
|
||||
temperature: -1.5
|
||||
wind_direction: 56
|
||||
wind_speed: 14.3
|
||||
---
|
||||
|
||||
L'idée n'est pas nouvelle, évidemment, mais je voulais réaliser mon propre outil de gestion d'une blacklist DNS.
|
||||
C'est une solution que je trouve, de très loin, supérieure à [AdBlock Plus](https://adblockplus.org/), pratiquement la première extension que tout le monde installe avec son navigateur préféré.
|
||||
|
||||
Pourquoi supérieure ?
|
||||
Je vois au moins deux avantages:
|
||||
|
||||
- Le blocage peut s'appliquer à tout un réseau, pas juste une seule machine
|
||||
- Le blocage s'applique à toute application, pas seulement le navigateur
|
||||
|
||||
Bien sûr, il y a aussi quelques inconvénients:
|
||||
|
||||
- Il faut être capable de monter un serveur DNS
|
||||
- Un blocage par DNS est moins précis qu'AdBlock Plus (pas possible de ne cibler qu'une publicité spécifique sur une page)
|
||||
|
||||
Mon application est un outil en mode console, basé sur le framework [Lumen](https://lumen.laravel.com/).
|
||||
C'est donc un outil écrit en PHP.
|
||||
À la base, je l'ai écris pour mon usage personnel, mais je me suis dis que peu de modifications seraient nécessaires pour en faire une application à diffusion plus large.
|
||||
|
||||
J'ai donc intégré la possibilité d'écrire des parseurs pour différents formats de listes et le support pour différents serveurs DNS.
|
||||
Ainsi, bien que je n'ai écris qu'un parseur pour les listes contenant un hôte par ligne et une classe de support pour bind, il sera très facile de supporter d'autres sources et d'autres serveurs rapidement.
|
||||
D'ailleurs, [c'est déjà prévu](https://git.athaliasoft.com/Richard/Blacklist/issues).
|
||||
|
||||
- [Le dépôt gitlab](https://git.athaliasoft.com/Richard/Blacklist)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 66 KiB |
@@ -0,0 +1,322 @@
|
||||
---
|
||||
comments_url: https://com.richard-dern.fr/post/547
|
||||
date: '2016-02-22 22:22:28'
|
||||
links:
|
||||
- lang: fr
|
||||
name: Page d'origine sur LinuxFr
|
||||
url: https://linuxfr.org/users/richarddern/journaux/installer-un-serveur-firefox-accounts-et-firefox-sync
|
||||
tags:
|
||||
- Firefox Sync
|
||||
- Auto-hébergement
|
||||
- Firefox
|
||||
title: Installer un serveur Firefox Accounts et Firefox Sync
|
||||
weather:
|
||||
humidity: 78
|
||||
illuminance: 0.0
|
||||
precipitations: false
|
||||
pressure: 1010.1
|
||||
source:
|
||||
- open-meteo
|
||||
temperature: 8.4
|
||||
wind_direction: 238
|
||||
wind_speed: 22.5
|
||||
---
|
||||
|
||||
> Depuis longtemps Firefox, comme d'autres navigateurs, permet de stocker ses données dans le Cloud pour pouvoir les sauvegarder et facilement les partager entre plusieurs instances du navigateur.
|
||||
> Et en plus, on peut l'auto-héberger !
|
||||
> Suivez le guide.
|
||||
|
||||
## Pré-requis globaux
|
||||
|
||||
On va partir du principe qu'on veut un backend sous MySQL.
|
||||
|
||||
- git
|
||||
- [node](https://nodejs.org/en/download/)
|
||||
- [bower](http://bower.io/)
|
||||
- mysql ou équivalent
|
||||
|
||||
Je recommande de tout mettre dans _/opt_, mais vous êtes libres de faire comme bon vous semble.
|
||||
|
||||
L'ensemble préfère naturellement les connexions chiffrées.
|
||||
Équipez-vous donc de certificats (personnellement, j'opte pour un par serveur accessible de l'extérieur), faut de quoi votre serveur de synchronisation ne fonctionnera pas correctement.
|
||||
|
||||
## Backend MySQL
|
||||
|
||||
On récupère les sources:
|
||||
|
||||
```
|
||||
git clone https://github.com/mozilla/fxa-auth-db-mysql.git
|
||||
cd fxa-auth-db-mysql
|
||||
npm install
|
||||
```
|
||||
|
||||
On créé le fichier de configuration:
|
||||
|
||||
```
|
||||
nano config/prod.json
|
||||
```
|
||||
|
||||
```
|
||||
{
|
||||
"master": {
|
||||
"host": "127.0.0.1",
|
||||
"user": "root",
|
||||
"password": "",
|
||||
"database": "fxaccounts"
|
||||
},
|
||||
"slave": {
|
||||
"host": "127.0.0.1",
|
||||
"user": "root",
|
||||
"password": "",
|
||||
"database": "fxaccounts"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Notez que comme _fxa-auth-server_ et _fxa-content-server_ que nous verrons plus loin, _fxa-auth-db-mysql_ fait appel à [convict](https://github.com/mozilla/node-convict) pour la gestion de la configuration.
|
||||
Si vous avez besoin d'autres paramètres de configuration que ceux que nous venons de créer, regardez le fichier _config/config.js_, et modifiez le fichier _config/prod.json_ en conséquence.
|
||||
|
||||
Notez également que la base de données n'a pas besoin d'être créée à l'avance.
|
||||
|
||||
Vous pouvez ensuite démarrer le serveur et vous assurer que tout va bien:
|
||||
|
||||
```
|
||||
npm start
|
||||
```
|
||||
|
||||
## fxa-auth-server
|
||||
|
||||
```
|
||||
cd /opt
|
||||
git clone https://github.com/mozilla/fxa-auth-server.git
|
||||
cd fxa-auth-server
|
||||
npm install
|
||||
```
|
||||
|
||||
Lancez une première fois le serveur pour générer les clés de chiffrement:
|
||||
|
||||
```
|
||||
npm start
|
||||
```
|
||||
|
||||
Vous devriez voir la sortie suivante:
|
||||
|
||||
```
|
||||
> npm start
|
||||
|
||||
> fxa-auth-server@1.56.0 start /opt/fxa-auth-server
|
||||
> NODE_ENV=dev scripts/start-local.sh 2>&1
|
||||
|
||||
Generating keypair
|
||||
Secret Key saved: /opt/fxa-auth-server/config/secret-key.json
|
||||
Public Key saved: /opt/fxa-auth-server/config/public-key.json
|
||||
fxa-auth-server.INFO: [...]
|
||||
```
|
||||
|
||||
Arrêtez ensuite le serveur en faisant <kbd>Control + C</kbd>
|
||||
|
||||
Modifiez le fichier de configuration:
|
||||
|
||||
```
|
||||
nano .env.dev
|
||||
```
|
||||
|
||||
```
|
||||
PUBLIC_URL=https://ffaccounts.example.org
|
||||
IP_ADDRESS=0.0.0.0
|
||||
CONTENT_SERVER_URL=https://ffcontent.example.org
|
||||
[...]
|
||||
USE_TLS=true
|
||||
TLS_KEY_PATH=/etc/ssl/private/ffaccounts.key
|
||||
TLS_CERT_PATH=/etc/ssl/private/ffaccounts.crt
|
||||
```
|
||||
|
||||
Dans le cas présent, remplacez les domaines par les vôtres.
|
||||
Notez que l'on va [reverse-proxyfier](https://fr.wikipedia.org/wiki/Proxy_inverse) tout ça, donc dans votre serveur web préféré, il faudra configurer un reverse proxy pour _ffaccounts.example.org_ pointant sur l'adresse de votre serveur (127.0.0.1 si le serveur web et le serveur de comptes firefox sont sur la même machine) et sur le port 9000.
|
||||
|
||||
De même, le reverse proxy de _ffcontent.example.org_ pointera sur le serveur de contenu (voir plus bas) sur le port 3030.
|
||||
|
||||
Démarrez le serveur afin de vous assurer que tout va bien:
|
||||
|
||||
```
|
||||
npm start
|
||||
```
|
||||
|
||||
Vous devriez voir un bloc JSON avec votre configuration.
|
||||
|
||||
## fxa-content-server
|
||||
|
||||
```
|
||||
cd /opt
|
||||
git clone https://github.com/mozilla/fxa-content-server.git
|
||||
cd fxa-content-server
|
||||
npm install
|
||||
```
|
||||
|
||||
Si vous installez _fxa-content-server_ en tant que root, entrez la commande suivante:
|
||||
|
||||
```
|
||||
bower --allow-root update --config.interactive=false -s
|
||||
```
|
||||
|
||||
Si vous ne l'installez pas en tant que root:
|
||||
|
||||
```
|
||||
npm postinstall
|
||||
```
|
||||
|
||||
Lancez le serveur:
|
||||
|
||||
```
|
||||
npm start
|
||||
```
|
||||
|
||||
Ce qui aura pour effet de créer le fichier _server/config/local.json_.
|
||||
|
||||
Il se peut que cette commande s'arrête brusquement:
|
||||
|
||||
```
|
||||
fxa-content-server.CRITICAL: uncaughtException Error: ENOENT: no such file or directory, open '/opt/fxa-content-server/node_modules/express-able/node_modules/able/bundle.js'
|
||||
```
|
||||
|
||||
Lancez la commande suivante pour corriger le problème:
|
||||
|
||||
```
|
||||
cd /opt/fxa-content-server/node_modules/express-able/node_modules/able/
|
||||
npm run bundle
|
||||
```
|
||||
|
||||
Puis, relancez le serveur:
|
||||
|
||||
```
|
||||
cd /opt/fxa-content-server
|
||||
npm start
|
||||
```
|
||||
|
||||
Cette fois, il ne devrait plus y avoir d'erreur.
|
||||
Arrêtez le serveur avec <kbd>Control + C</kbd>, il faut maintenant le configurer.
|
||||
|
||||
```
|
||||
nano server/config/local.json
|
||||
```
|
||||
|
||||
```
|
||||
{
|
||||
"public_url": "https://ffcontent.example.org",
|
||||
"fxaccount_url": "https://ffaccounts.example.org",
|
||||
"oauth_client_id": "98e6508e88680e1a",
|
||||
"oauth_url": "http://127.0.0.1:9010",
|
||||
"profile_url": "http://127.0.0.1:1111",
|
||||
"profile_images_url": "http://127.0.0.1:1112",
|
||||
"client_sessions": {
|
||||
"cookie_name": "session",
|
||||
"secret": "YOU MUST CHANGE ME",
|
||||
"duration": 86400000
|
||||
},
|
||||
"env": "development",
|
||||
"use_https": false,
|
||||
"static_max_age" : 0,
|
||||
"i18n": {
|
||||
"supportedLanguages": ["af", "an", "ar", "as", "ast", "az", "be", "bg", "bn-BD", "bn-IN", "br", "bs", "ca", "cs", "cy", "da", "de", "dsb", "el", "en", "en-GB", "en-ZA", "eo", "es", "es-AR", "es-CL", "es-MX", "et", "eu", "fa", "ff", $
|
||||
},
|
||||
"route_log_format": "dev_fxa",
|
||||
"logging": {
|
||||
"fmt": "pretty",
|
||||
"level": "debug"
|
||||
},
|
||||
"static_directory": "app",
|
||||
"allowed_parent_origins": ["http://127.0.0.1:8080"],
|
||||
"csp": {
|
||||
"enabled": true,
|
||||
"reportUri": "/_/csp-violation"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Le plus important est de changer l'URL public pour qu'il corresponde à la variable *CONTENT_SERVER_URL*, que l'on a spécifié dans la configuration de _fxa-auth-accounts_.
|
||||
Assurez-vous aussi de rajouter *fxaccount_url* puisque ce paramètre n'existe pas dans la configuration générée automatiquement.
|
||||
|
||||
Une fois la configuration faite, on relance le serveur:
|
||||
|
||||
```
|
||||
npm start
|
||||
```
|
||||
|
||||
On devrait maintenant pouvoir se connecter, créer son compte et le valider par mail.
|
||||
Accédez à votre serveur avec l'adresse _https://ffcontent.example.org_ (en remplaçant bien sûr par votre propre domaine), et créez le compte.
|
||||
|
||||
Une fois la validation par mail effectuée, une "erreur inattendue" apparaitra.
|
||||
Je ne sais pas à quoi elle est dûe, mais ne semble pas affecter négativement la suite.
|
||||
On ne s'en soucie donc pas pour l'instant, mais si quelqu'un a une explication/solution, je suis preneur !
|
||||
|
||||
## Serveur de synchronisation
|
||||
|
||||
Enfin, dernière pièce de notre puzzle, le serveur de synchronisation.
|
||||
La [page dédiée](http://docs.services.mozilla.com/howtos/run-sync-1.5.html) de la documentation fournie par Mozilla est plus accessible et plus à jour que celles concernant le serveur Firefox Accounts.
|
||||
Voici tout de même mon guide, par soucis de centralisation et d'exhaustivité.
|
||||
|
||||
Les paquets suivants sont requis:
|
||||
|
||||
```
|
||||
python-dev git-core python-virtualenv g++
|
||||
```
|
||||
|
||||
On récupère les sources et on compile:
|
||||
|
||||
```
|
||||
cd /opt
|
||||
git clone https://github.com/mozilla-services/syncserver
|
||||
cd syncserver
|
||||
make build
|
||||
```
|
||||
|
||||
On configure:
|
||||
|
||||
```
|
||||
nano syncserver.ini
|
||||
```
|
||||
|
||||
```
|
||||
[syncserver]
|
||||
public_url = https://ffsync.example.org/
|
||||
sqluri = pymysql://root:motdepasse@127.0.0.1/fxsync
|
||||
force_wsgi_environ = true
|
||||
|
||||
[browserid]
|
||||
backend = tokenserver.verifiers.LocalVerifier
|
||||
audiences = https://ffsync.example.org
|
||||
```
|
||||
|
||||
Contrairement à _fxa-auth-db-mysql_, ici la base de données doit être créée avant de lancer le serveur.
|
||||
Dans mon cas, je l'ai nommée _fxsync_.
|
||||
|
||||
Là aussi, on va créer un reverse proxy dans son serveur web préféré, pour _ffsync.example.org_ vers l'adresse du serveur de synchronisation, sur le port 5000.
|
||||
|
||||
On place la variable *force_wsgi_environ* à _true_ pour éviter que le scheme ne pose problème avec le reverse proxy (qui est en HTTPs) et ce serveur (qui est en HTTP).
|
||||
|
||||
Mettez à jour la valeur de _secret_, comme indiqué en commentaire dans le fichier.
|
||||
|
||||
On peut lancer le serveur:
|
||||
|
||||
```
|
||||
make serve
|
||||
```
|
||||
|
||||
## Configuration de firefox
|
||||
|
||||
Maintenant que tout est installé, reste à configurer firefox pour prendre en compte notre propre serveur de synchronisation.
|
||||
Fiez-vous à la capture d'écran suivante pour ajuster vos paramètres (dans _about:config_):
|
||||
|
||||
|
||||
|
||||
Remplacez les domaines par les vôtres, bien entendu.
|
||||
|
||||
Remarquez qu'une option _identity.fxaccounts.allowHttp_ a été créée.
|
||||
Si vous voulez vous aventurer à créer un serveur de synchronisation sans chiffrement, positionnez cette valeur à _true_.
|
||||
|
||||
Enfin, rendez-vous dans les options, onglet "Sync", et connectez-vous avec le compte précédemment créé.
|
||||
Firefox devrait pouvoir se synchroniser sans problème.
|
||||
|
||||
À noter que si vous cliquez sur le lien "Gérer le compte" une fois configuré, vous aurez la même erreur inattendue que précédemment, ce qui m'incite à croire qu'elle est liée à l'absence d'un serveur d'identité.
|
||||
Mais je laisse ça à un hypothétique futur article.
|
||||
Reference in New Issue
Block a user