Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2021-02-06 Par sujet Arnaud 
Le 06.02.21 à 10:31, Marc SCHAEFER a écrit :
> On Sat, Feb 06, 2021 at 02:45:26AM +0100, Arnaud wrote:

>>> Dans ce cas, la seule solution est que les données soient stockées à
>>> part et que les conteneurs soient générables automatiquement par scripts
>>> ou Docker compose ou autre, et on les regénère régulièrement à partir
>>> d'images de bases mises à jour.
>>
>> Oui, données à part, c'est une de mes finalités.
> 
>> Je penchais pour GlusterFS, ou autres, j'en suis à regarder ce qui est 
>> possible actuellement.
> 
> GlusterFS ne peut pas être utilisé sur la partition où Docker gère son
> copy-on-write, du moins pour le moment. C'est peut-être possible en NFS.
> 
> Mon concept est alors plus simple: j'ai un /private (conteneur
> uniquement) et un /shared (partage de données entre conteneurs d'un même
> utilisateur) en GlusterFS répliqué, par contre les conteneurs eux-mêmes
> sont locaux sur mSATA SSD.
> 
> Voir la documentation et la vidéo:
>https://wiki.alphanet.ch/Sandbox/ALPHANETDSQuickStartGuide
>https://login.alphanet.ch/~schaefer/tmp/ds-end-user.mp4

Le CERN a publié une doc concernant OVIRT sur 2 serveurs + 1 serveur de données.
Ils utilisent GlusterFS pour la VM en HA qui auto-héberge ovirt-engine, en plus 
de Ceph pour les VMs.

GlusterFS serait sur des ports réseaux dédiés, et possédant des disques dédiés 
sur les machines elles-mêmes, dans le même style qu'ils ont fait.

Merci pour les liens
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2021-02-06 Par sujet Arnaud 
Le 06.02.21 à 12:50, Daniel Cordey a écrit :
> On 06/02/2021 10:31, Marc SCHAEFER wrote:
> 
>>
 Dans ce cas, la seule solution est que les données soient stockées à
 part et que les conteneurs soient générables automatiquement par scripts
 ou Docker compose ou autre, et on les regénère régulièrement à partir
 d'images de bases mises à jour.
>>> Oui, données à part, c'est une de mes finalités.
> 
> Je me greffe sur cette discussion pour faire un petit commentaire plus 
> général en ce qui concerne la gestion des "conteneurs".
> 
> La question est de bien définir l'usage. Si l'objectif est de remplacer N 
> serveurs (ou services) de manière à les isolés sur un seul "host", la 
> solution la plus tendance à l'heure actuelle est "Ansible". Il y a encore pas 
> mal de gens qui font du Puppet, mais il est plus logique de s'orienter vers 
> Ansible qui offre plus de performance et de facilités. Néanmoins, chaque 
> service devra avoir sa propre config et il faudra quand même gérer toutes ces 
> entités.
> 
> Les choses se complique lorsque l'on veut faire de la redondance ou du 
> load-balancing. On se trouve alors confronté à la notion de "découverte des 
> services", qui peuvent bouger avec ces exigences. C'est justement l'autre 
> objectif d'utilisation des conteneurs. Ceci s'appelle l'0erchestration des 
> services et est un domaine en soit. Après quelques années d'hésitations et de 
> flou, Kubernetes semble être le choix par défaut et le plus logique. 
> Kubernetes est intimement lié aux conteneurs et principalement à Docker 
> aujourd'hui. Il permet de définir une configuration standard pour un service, 
> qui peut être lancé par goupe ou en séquence, tout en intégrant les notions 
> évoquées plus tôt (redondance, fail-over, load-balancing). Cela permet aussi 
> de faire du "Scaling". Naturellement, c'est une couche d'administration 
> au-dessus de Docker, mais c'est aussi le moyen le plus simple et élégant 
> d'obtenir ce genre de service en masse. Il y a des fonctionnalités qui 
> permettent de planifier des
> mises à jour des "serveurs", avec des notions de gestion de production assez 
> avancées. Il ne faut pas négligé la partie "file-system", qui est un point 
> essentiel dans le domaine de la redondance/fail-over/non-stop... mais là on 
> entre alors dans un monde encore plus complexe qui implique quasi 
> systématiquement de repenser son architecture de gestion des données (NoSQL, 
> etc.)
> 
> En conclusion, la virtualisation du style hyper-v, kvm, etc. permet de 
> construire un monde très hétérogène, tout en minimisant l'utilisation du 
> matériel, alors que la virtualisation système (docker, LXC/LXD) offre un gros 
> gain de performance et de ressources, mais en ayant l'obligation d'être 
> homogène au niveau de l'OS.  Kubernetes permet d'entrer dans le monde du 
> big-data et offre une quantité d'outils et de solutions pour ceux qui ont 
> besoin de ces fonctionnalités; mais là on ne peut plus se permettre de gérer 
> tout ça avec des scripts et Ansible.

Oui ça aussi c'est en cours. k8s, k3s/k3d, k1s, minikube, etc. . Il y en a un 
paquet.

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2021-02-06 Par sujet Daniel Cordey 

On 06/02/2021 10:31, Marc SCHAEFER wrote:




Dans ce cas, la seule solution est que les données soient stockées à
part et que les conteneurs soient générables automatiquement par scripts
ou Docker compose ou autre, et on les regénère régulièrement à partir
d'images de bases mises à jour.

Oui, données à part, c'est une de mes finalités.


Je me greffe sur cette discussion pour faire un petit commentaire plus 
général en ce qui concerne la gestion des "conteneurs".


La question est de bien définir l'usage. Si l'objectif est de remplacer 
N serveurs (ou services) de manière à les isolés sur un seul "host", la 
solution la plus tendance à l'heure actuelle est "Ansible". Il y a 
encore pas mal de gens qui font du Puppet, mais il est plus logique de 
s'orienter vers Ansible qui offre plus de performance et de facilités. 
Néanmoins, chaque service devra avoir sa propre config et il faudra 
quand même gérer toutes ces entités.


Les choses se complique lorsque l'on veut faire de la redondance ou du 
load-balancing. On se trouve alors confronté à la notion de "découverte 
des services", qui peuvent bouger avec ces exigences. C'est justement 
l'autre objectif d'utilisation des conteneurs. Ceci s'appelle 
l'0erchestration des services et est un domaine en soit. Après quelques 
années d'hésitations et de flou, Kubernetes semble être le choix par 
défaut et le plus logique. Kubernetes est intimement lié aux conteneurs 
et principalement à Docker aujourd'hui. Il permet de définir une 
configuration standard pour un service, qui peut être lancé par goupe ou 
en séquence, tout en intégrant les notions évoquées plus tôt 
(redondance, fail-over, load-balancing). Cela permet aussi de faire du 
"Scaling". Naturellement, c'est une couche d'administration au-dessus de 
Docker, mais c'est aussi le moyen le plus simple et élégant d'obtenir ce 
genre de service en masse. Il y a des fonctionnalités qui permettent de 
planifier des mises à jour des "serveurs", avec des notions de gestion 
de production assez avancées. Il ne faut pas négligé la partie 
"file-system", qui est un point essentiel dans le domaine de la 
redondance/fail-over/non-stop... mais là on entre alors dans un monde 
encore plus complexe qui implique quasi systématiquement de repenser son 
architecture de gestion des données (NoSQL, etc.)


En conclusion, la virtualisation du style hyper-v, kvm, etc. permet de 
construire un monde très hétérogène, tout en minimisant l'utilisation du 
matériel, alors que la virtualisation système (docker, LXC/LXD) offre un 
gros gain de performance et de ressources, mais en ayant l'obligation 
d'être homogène au niveau de l'OS.  Kubernetes permet d'entrer dans le 
monde du big-data et offre une quantité d'outils et de solutions pour 
ceux qui ont besoin de ces fonctionnalités; mais là on ne peut plus se 
permettre de gérer tout ça avec des scripts et Ansible.


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2021-02-06 Par sujet Marc SCHAEFER 
On Sat, Feb 06, 2021 at 02:45:26AM +0100, Arnaud wrote:
> Mais je pensais pas qu'un apu2 pourrait faire fonctionner autant de 
> conteneurs.

Ca dépend ce qu'il y a dedans, bien sûr. Et le copy-on-write des
exécutables semble assez bien fonctionner.

Evidemment, si on y met du Java ou x2go, ça bouffe un peu plus de RAM et
de performance.

> J'ai pas trop l'habitude des conteneurs, donc quadcore et 4GB, ça me fait un 
> peu bugger pour 40 conteneurs :)
> J'ai un raspi 4 de côté, vais regarder.

La performance du raspi 4 est comparable, sauf pour le chiffrement ou
l'apu2 est meilleur.  Et après, il y a aussi la question du matériel
libre (apu2) ou non (raspi 4).

> > Dans ce cas, la seule solution est que les données soient stockées à
> > part et que les conteneurs soient générables automatiquement par scripts
> > ou Docker compose ou autre, et on les regénère régulièrement à partir
> > d'images de bases mises à jour.
> 
> Oui, données à part, c'est une de mes finalités.

> Je penchais pour GlusterFS, ou autres, j'en suis à regarder ce qui est 
> possible actuellement.

GlusterFS ne peut pas être utilisé sur la partition où Docker gère son
copy-on-write, du moins pour le moment. C'est peut-être possible en NFS.

Mon concept est alors plus simple: j'ai un /private (conteneur
uniquement) et un /shared (partage de données entre conteneurs d'un même
utilisateur) en GlusterFS répliqué, par contre les conteneurs eux-mêmes
sont locaux sur mSATA SSD.

Voir la documentation et la vidéo:
   https://wiki.alphanet.ch/Sandbox/ALPHANETDSQuickStartGuide
   https://login.alphanet.ch/~schaefer/tmp/ds-end-user.mp4
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2021-02-05 Par sujet Arnaud 
Le 05.02.21 à 22:06, Marc SCHAEFER a écrit :
> On Fri, Feb 05, 2021 at 09:25:04PM +0100, Arnaud wrote:
>> J'ai un peu de peine actuellement à comprendre cela. Sur des hotes peu 
>> puissants ?
> 
> Tout est relatif.  Disons que sur un apu2 avec 4 GB de mémoire, je
> tourne plus d'une quarantaine de conteneurs Debian.

Intéressant, merci du retour. 

> Dès le moment que le matériel est surdimensionné, ça marchera tout aussi
> bien avec kvm qu'avec les cgroups (lxc, docker, ...).

Oui, j'ai volontairement pris surdimensionné, mais en cherchant à un prix 
abordable.
Ce qui fera un cluster hautement surdimensionné à prix plus ou moins abordable. 
J'ai toutefois espoir qu'il servira réellement un jour.

Mais je pensais pas qu'un apu2 pourrait faire fonctionner autant de conteneurs.
J'ai pas trop l'habitude des conteneurs, donc quadcore et 4GB, ça me fait un 
peu bugger pour 40 conteneurs :)
J'ai un raspi 4 de côté, vais regarder.

> Malheureusement, ce que je constate par exemple avec Docker c'est que
> les gens ne mettent pas à jour leurs conteneurs, ou, pire, se basent sur
> des images de base vérolées.

Ca, il y aura toujours ce genre de trucs... Je fais mon possible pour éviter ce 
type de pratiques.

> Dans ce cas, la seule solution est que les données soient stockées à
> part et que les conteneurs soient générables automatiquement par scripts
> ou Docker compose ou autre, et on les regénère régulièrement à partir
> d'images de bases mises à jour.

Oui, données à part, c'est une de mes finalités.
Je penchais pour GlusterFS, ou autres, j'en suis à regarder ce qui est possible 
actuellement.

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2021-02-05 Par sujet Marc SCHAEFER 
On Fri, Feb 05, 2021 at 09:25:04PM +0100, Arnaud wrote:
> J'ai un peu de peine actuellement à comprendre cela. Sur des hotes peu 
> puissants ?

Tout est relatif.  Disons que sur un apu2 avec 4 GB de mémoire, je
tourne plus d'une quarantaine de conteneurs Debian.

Même avec la déduplification de RAM (qui coûte des cycles CPU), je doute
que je puisse lancer 40 VM kvm Debian.  Mais à tester!

Dès le moment que le matériel est surdimensionné, ça marchera tout aussi
bien avec kvm qu'avec les cgroups (lxc, docker, ...).

> N'est-ce pas là que les compétences en DevOps interviennent ?
> Ansible/etc., gestion par scripts, et autres ?

Tout à fait.  Soit on se repose sur une distribution éprouvée, soit on
administre par scripts, soit on fait les deux.

> Je dois avouer que les détruire et les recréer ne m'est même pas
> passer par la tête, surtout chaque jour.  Mais créer des playbooks qui
> recréent, configurent et modifient automatiquement toutes les VM est
> en cours.

Pas de souci tant que les mises à jour et la veille sécurité sont
effectués.  On peut imaginer d'activer les mises à jour automatiques, ou
de les propager par scripts.

Malheureusement, ce que je constate par exemple avec Docker c'est que
les gens ne mettent pas à jour leurs conteneurs, ou, pire, se basent sur
des images de base vérolées.

Dans ce cas, la seule solution est que les données soient stockées à
part et que les conteneurs soient générables automatiquement par scripts
ou Docker compose ou autre, et on les regénère régulièrement à partir
d'images de bases mises à jour.
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2021-02-05 Par sujet Arnaud 
Le 05.02.21 à 20:27, Marc SCHAEFER a écrit :
> On Fri, Feb 05, 2021 at 08:11:39PM +0100, Arnaud wrote:
>> Mais pourrais-je me permettre de demander en quoi LXC est beaucoup plus 
>> efficace que KVM?
> 
[...]
> On peut toutefois améliorer les performances de la virtualisation
> lourde, en coupant les jambes du kernel dans la VM (recompilation d'un
> kernel Linux sans ses couches basses comme fait WSL2), ou y intégrer des
> pilotes spécifiques (Guest extensions, paravirtualisation: le guest
> devient conscient qu'il est virtualisé) améliorant la performance ou
> permettant de contrôler certaines ressources depuis le host (balloon
> driver, etc).

J'ai un peu de peine actuellement à comprendre cela. Sur des hotes peu 
puissants ?
Même durant le backup de toutes les VMs, et en essayant de charger les vms, je 
ne vois pas tellement de différence. 
Mais comme dit précédemment, il faudrait que je les charge plus.

> Il ne faut pas oublier que la virtualisation ajoute N conteneurs ou VM
> plus le host de base à maintenir (mises à jour de sécurité p.ex.), sauf
> si l'on part dans une approche où on détruit les conteneurs chaque jour
> (ou au minimum à chaque annonce de sécurité de n'importe lequel des
> composants logiciels du conteneur) et on les recrée depuis des images à
> jour avec des scripts d'auto-création (p.ex. Docker compose, lxd, etc).

N'est-ce pas là que les compétences en DevOps interviennent ? Ansible/etc., 
gestion par scripts, et autres ?
Je me vois mal me connecter à chaque VM pour y faire les mises à jour par 
exemple (à la limite il y a pssh/etc.).
Ni les détruire/recréer juste pour des mises à jour, ou même modifier une 
configuration sur tout un groupe de VM

Je dois avouer que les détruire et les recréer ne m'est même pas passer par la 
tête, surtout chaque jour.
Mais créer des playbooks qui recréent, configurent et modifient automatiquement 
toutes les VM est en cours.

> Typiquement, je n'utilise pas de virtualisation lourde en production
> actuellement, uniquement de la virtualisation légère lxc ou Docker, et
> je travaille plutôt avec des mises à jour automatiques ou
> semi-automatiques via une distribution complète Debian, et surtout pas
> avec des images de base vérolées de github.

Cela n'a pas posé de problèmes de mises à jour automatiques ?
Concernant des images github, aucune idée. Je préfère utiliser soit des 
templates, soit un role ansible qui crée la vm et la configure

Sinon, je ne vois toujours pas en quoi LXC est plus efficace que KVM.
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2021-02-05 Par sujet Marc SCHAEFER 
On Fri, Feb 05, 2021 at 08:11:39PM +0100, Arnaud wrote:
> Mais pourrais-je me permettre de demander en quoi LXC est beaucoup efficace 
> que KVM?

lxc et Docker utilisent les services des cgroups du kernel Linux et
proposent donc des conteneurs plutôt que des machines virtuelles.
J'appelle cela de la virtualisation légère.

La différence principale est assez simple: les conteneurs ne permettent
pas d'exécuter un autre kernel que celui de l'host. Tourner du Microsoft
dans un conteneur sous Linux n'est alors possible qu'avec Wine, et le
contraire avec WSL1 (aucune idée si encore supporté par Microsoft,
aujourd'hui ils font plutôt du WSL2 avec un mini-kernel Linux en
virtualisation lourde sous Microsoft HyperV dans lequel ils lancent les
conteneurs Linux -- apparemment plus fiable et plus performant que
WSL1).

kvm, comme VirtualBox, xen, Microsoft HyperV permettent à contrario
d'exécuter un autre kernel dans la machine virtuelle. Il s'agit de
virtualisation lourde.

En fait, les conteneurs sont d'une performance proche à exécuter une
application nativement sur le host, mais avec du confinement / de
l'isolation plus ou moins configurable.

On peut toutefois améliorer les performances de la virtualisation
lourde, en coupant les jambes du kernel dans la VM (recompilation d'un
kernel Linux sans ses couches basses comme fait WSL2), ou y intégrer des
pilotes spécifiques (Guest extensions, paravirtualisation: le guest
devient conscient qu'il est virtualisé) améliorant la performance ou
permettant de contrôler certaines ressources depuis le host (balloon
driver, etc).

Il ne faut pas oublier que la virtualisation ajoute N conteneurs ou VM
plus le host de base à maintenir (mises à jour de sécurité p.ex.), sauf
si l'on part dans une approche où on détruit les conteneurs chaque jour
(ou au minimum à chaque annonce de sécurité de n'importe lequel des
composants logiciels du conteneur) et on les recrée depuis des images à
jour avec des scripts d'auto-création (p.ex. Docker compose, lxd, etc).

Typiquement, je n'utilise pas de virtualisation lourde en production
actuellement, uniquement de la virtualisation légère lxc ou Docker, et
je travaille plutôt avec des mises à jour automatiques ou
semi-automatiques via une distribution complète Debian, et surtout pas
avec des images de base vérolées de github.

A nouveau `utilisabilité vs sécurité et maintenabilité'.
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2021-02-05 Par sujet Arnaud 
Le 27.11.20 à 12:23, Open Net Sàrl / Jean-Marc Vandel a écrit :
>> Notre optique technique est une base de proxmox avec du Debian par  
>> dessus en KVM et un CentOS pour un FreeIPA (annuaire LDAP/Kerberos). On  
>> utilise en effet ansible (c'est assez génial) et LibreNMS pour la  
>> supervision de l'ensemble, et Gitlab pour développer nos playbooks  
>> ansible. Bref, on peut faire un petit chaton avec une grosse workstation  
>> d'occasion et deux disques en RAID logiciel.
>   
>   J'utilise Proxmox en production depuis presque 10 ans alors je me permets 
> ceci :  
> - Pourquoi utiliser KVM alors que LXC est beaucoup plus efficace ?  
> - Plutôt que du software RAID mdadm, j'utilise désormais ZFS en mirroring.  
> - Je recommande de mettre le système sur 2 SSD NVMe et de garder un espace 
> libre pour y mettre le ZIL et le L2ARC des éventuels HDD.  

Bonjour,

Je suis assez newbi avec Proxmox, mais bien que le pc qui l'acceuil soit encore 
bon marché, il a de bonnes capacités.
Pour avoir une idée de son peu de charge actuelle totale: 34 VMS, 1.2% à 9% CPU 
(sur 32 threads), 39% mémoire, 0.4% espace disque (2xNVME/HDD)

Mais pourrais-je me permettre de demander en quoi LXC est beaucoup efficace que 
KVM?
Mais cela m'intéresserait d'avoir votre avis, peut-être d'autres aussi?
(actuellement toutes mes VMs sont stockées en qcow2 sur un disque dédié, afin 
de ne pas me prendre la tête en cas de migration pour des fins de tests)

Linux Conf 2021: "Containers are hideously undebuggable black boxes and we 
never should have invented them" :)
https://www.youtube.com/watch?v=pPZsN_urpqw

Cordialement,
Arnaud


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-27 Par sujet Arnaud 
Le 26.11.20 à 14:04, Frédéric Dumas a écrit :
>> Arnaud a écrit :
>> Personnellement, je suis en train de créer mon propre cloud personnel, 
>> auto-hébergé chez moi :)
> 
> Tu utiliseras Nextcloud ou autre chose, Arnaud ?

Mon but et de créer un mini-datacenter, gestion emails, sites web, tester 
divers projets, voir créer le mien.
Donc nextcloud pourquoi pas, mais la nouvelle machine qui arrive est assez 
puissante pour ne pas me restreindre à que nextcloud :)

Je dois toujours décider de ce que je veux y mettre comme base...
J'ai eu plusieurs avis, et je n'arrive pas à me décider, donc il faut que j'en 
teste plusieurs.

Proxmox pourquoi pas (mais c'est debian la base ^^ je peux essayer en tout 
cas), oVirt, ou autre chose.

Cordialement



OpenPGP_0xEA0DA251B671CC2A.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-27 Par sujet Open Net Sàrl / Jean-Marc Vandel 

Hello !  
  
> Notre optique technique est une base de proxmox avec du Debian par  
> dessus en KVM et un CentOS pour un FreeIPA (annuaire LDAP/Kerberos). On  
> utilise en effet ansible (c'est assez génial) et LibreNMS pour la  
> supervision de l'ensemble, et Gitlab pour développer nos playbooks  
> ansible. Bref, on peut faire un petit chaton avec une grosse workstation  
> d'occasion et deux disques en RAID logiciel.
  
  J'utilise Proxmox en production depuis presque 10 ans alors je me permets 
ceci :  
- Pourquoi utiliser KVM alors que LXC est beaucoup plus efficace ?  
- Plutôt que du software RAID mdadm, j'utilise désormais ZFS en mirroring.  
- Je recommande de mettre le système sur 2 SSD NVMe et de garder un espace 
libre pour y mettre le ZIL et le L2ARC des éventuels HDD.  
  
  Meilleures amitiés,  
   
  
Jean-Marc Vandel  
CTO ● Ing. info. dipl. EPFL   
  
**Open Net Sàrl ● Odoo Gold Partner**  
[Rue de Genève 77 ](https://goo.gl/maps/VB68piUM4FARqnv76)  
1004 Lausanne VD   
[www.open-net.ch ](https://www.open-net.ch/)  
+41 21 701 42 45  
  

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-26 Par sujet Samuel Chenal 
Hello !

Concernant le système de chat, on parlait de signal sur cet échange.
C'est bien, mais cela reste une solution centralisée et qu'on ne peut
pas réellement installer.

Personnellement, je préfère Delta Chat. Nous utilisons XMPP/Jabber au
boulot chez itopie, mais cela reste malgré tout, une affaires de geeks
et de techniciens. Quand on compare Gajim avec des clients de chats de
type GAFAM, on est loin de créer l'adhésion. Avec Delta Chat, on est sur
du courriel (n'importe lequel) et c'est chiffré avec OpenPGP et
Autocrypt. On trouve des clients pour un peu toutes les plateformes et
ils sont assez bien fichus je trouve.

https://delta.chat/fr/

Une petite contrainte : j'ai vu qu'avec une adresse de courriel dédiée,
c'est plus simple et on s'évite des soucis.

Sinon, je pense qu'il faut suivre l'initiative des CHATONS de Framasoft.
Nous avions lancé l'idée de chaton-leman.ch il y a quelques années, mais
on avait du mal à trouver un porteur de projets (et nous n'avions pas
les disponibilités en interne). Là, il semble qu'on puisse relancer la
machine avec des coopérateurs motiviés.

Notre optique technique est une base de proxmox avec du Debian par
dessus en KVM et un CentOS pour un FreeIPA (annuaire LDAP/Kerberos). On
utilise en effet ansible (c'est assez génial) et LibreNMS pour la
supervision de l'ensemble, et Gitlab pour développer nos playbooks
ansible. Bref, on peut faire un petit chaton avec une grosse workstation
d'occasion et deux disques en RAID logiciel.

On se tient au courant concernant ce projet !

a+

Samuel

Le 26.11.20 à 11:43, Daniel Cordey a écrit :
>
> On 26.11.20 11:08, Arnaud wrote:
>> Tout comme on nous pousse coûte que coûte à utiliser un smartphone...
>
> Le monde du commerce se repose là-dessus et estime que tout le monde
> en a un en en fait le même usage. Il n'y a qu'à voir le nombre de site
> qui ont des logos FB et Twitter... Ensuite on the demande to adresse
> email pour t'envoyer les factures, sinon on te fait payer, etc.  C'est
> sans fin ...
>
>
>> Pour moi, les solutions non cloud qui avaient un certain impact lors
>> de défaillances,
>> sont remplacées par des solutions qui ont encore plus d'impact lors
>> de défaillances.
>
> Dans une solution cloud, on ne peut plus parler de
> haute-disponibilité, mais plutôt de non-stop. ceci implique de se
> démarquer des architecture classiques d'applications avec backup 1, 2,
> 3... On doit alors passer à des solutions basées sur des
> micro-services, utilisant massivement les conteneurs et des outils
> comme Kubernetes et ce qui gravite autours.
>
> Cela représente une révolution pour pratiquement toutes les
> entreprises et la très grande majorité, non seulement n'est pas prête,
> mais n'a même pas compris la problématique. Là dessus, les entreprises
> font le forcing et prennent des raccourcis en ce qui concerne la
> privatisation des données. Où seront hébergés les données dans le
> cloud ? Quid des backups ? Les données sont-elles encryptés ? Etc.
> Autant de questions auxquelles beaucoup d'entreprises n'ont pas
> réfléchis. D'autant qu'il ne faut pas compter sur les fournisseurs de
> solutions clouds pour attirer votre attention sur ces points ! En
> fait, les fournisseurs ne vont discuter GDPR que si vous leur en
> parlés et abordés les questions techniques à ce sujet. Sinons...
> silence radio et on laisse l'hébergeur faire ce qu'il veut. Sans
> compter que les département légaux des entreprises ne sont souvent pas
> à la page en ce qui concerne le cloud et ses implications; et je ne
> parle même pas des département chargés de négocier les contrats. Pour
> une grande majorité, la notion de SLA (Servive Level Agreement) ne
> fait même pas partie du contrat...
>
>> (enfin bon, comme d'hab je m'écarte fortement du sujet initial,
>> désolé ^^)
>>
> Oui, j'avoue être aussi coupable.
>
>
> dc
>
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

-- 
---
Samuel Chenal
https://www.ll-dd.ch
samuel.che...@ll-dd.ch
---

Merci d'utiliser des formats
de fichiers ouverts (comme ODF)




signature.asc
Description: OpenPGP digital signature
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-26 Par sujet Yann Lehmann 

Am 26.11.2020 um 14:04 schrieb Frédéric Dumas:



Tu utiliseras Nextcloud ou autre chose, Arnaud ?




Je peux recommander EGroupware pour cet usage. Je précise que ce qui 
suit n'est pas une pub, je suis juste un utilisateur satisfait.


On peur gérer ses contacts, son agenda et ses tâches (CalDAV et 
CardDAV), et il propose un gestionnaire de fichiers (WebDAV), bien que 
pas autant puissant dans ce domaine que Nextcoud et autres solutions 
dédiées.


Depuis 2020, il est possible d'intégrer Rocket.Chat et Guacamole (pour 
l'accès distant à son/ses desktop/s par VNC et RDP), ainsi que jitsi. 
Sans oublier un client webmail, pour l'accès à toutes ses boîtes aux 
lettres.


L'outil n'est pas tout simple à prendre en main au début, mais une fois 
la base installée, ça tourne sans problème. Il y a d'autres modules 
proposés que je ne connais et n'utilise pas, ainsi que la possibilité 
d'utiliser la plateforme pour l'authentification sur d'autres services 
(serveur OpenID Connect/OAuth2).


Par ailleurs, il y a régulièrement des mises à jour et des nouveautés, 
ainsi qu'une (petite) communauté d'utilisateurs (pas encore beaucoup de 
francophones...).


Et malheureusement en ce qui me concerne, depuis la version 2019, ça ne 
tourne que sur la plateforme amd64 (donc plus sur raspi et consorts), 
sauf si on veut vraiment mettre les mains dans le cambouis.


Perso, je trouve que l'outil mérite d'être découvert. La boîte qui le 
développe est en Allemagne et mise beaucoup sur l'open source et la 
protection des données.

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-26 Par sujet Frédéric Dumas 

Bonjour Laurent,
Bonjour à tous,

> Sur le principe, il faudrait leur demander avant de… te désincrire :-) Donc 
> ouvre un ticket auprès de leur service client et tu leurs demandes. La même 
> RGPD, sauf erreur, exige qu’ils soient capables de te livrer ta propre 
> propriété intellectuelle.

C’est la précaution que j’avais prise, d’où mon message ici.
Voilà la bafouille que j’ai faite passer ce matin par leur système « d’aide » 
intégré au compte utilisateur:

> I ask you to delete all personal data concerning me, according to the 
> requirements dictated by the RGPD, and to notify me when this is done.

On verra si ça répond.


> Arnaud a écrit :
> Personnellement, je suis en train de créer mon propre cloud personnel, 
> auto-hébergé chez moi :)

Tu utiliseras Nextcloud ou autre chose, Arnaud ?


> Laurent Franceschetti a écrit :
> Donc l’enjeu du présent ne serait plus uniquement le FLOSS 
> (Free-Libre-and-Open-Source-Software) mais le « FLOSC » (…-Cloud) ?

Mais faut pas que ce soit FLASC.
Bon ok je sors..


--
Frédéric Dumas
f.du...@ellis.siteparc.fr



___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-26 Par sujet Daniel Cordey 


On 26.11.20 11:08, Arnaud wrote:

Tout comme on nous pousse coûte que coûte à utiliser un smartphone...


Le monde du commerce se repose là-dessus et estime que tout le monde en 
a un en en fait le même usage. Il n'y a qu'à voir le nombre de site qui 
ont des logos FB et Twitter... Ensuite on the demande to adresse email 
pour t'envoyer les factures, sinon on te fait payer, etc.  C'est sans 
fin ...




Pour moi, les solutions non cloud qui avaient un certain impact lors de 
défaillances,
sont remplacées par des solutions qui ont encore plus d'impact lors de 
défaillances.


Dans une solution cloud, on ne peut plus parler de haute-disponibilité, 
mais plutôt de non-stop. ceci implique de se démarquer des architecture 
classiques d'applications avec backup 1, 2, 3... On doit alors passer à 
des solutions basées sur des micro-services, utilisant massivement les 
conteneurs et des outils comme Kubernetes et ce qui gravite autours.


Cela représente une révolution pour pratiquement toutes les entreprises 
et la très grande majorité, non seulement n'est pas prête, mais n'a même 
pas compris la problématique. Là dessus, les entreprises font le forcing 
et prennent des raccourcis en ce qui concerne la privatisation des 
données. Où seront hébergés les données dans le cloud ? Quid des backups 
? Les données sont-elles encryptés ? Etc. Autant de questions auxquelles 
beaucoup d'entreprises n'ont pas réfléchis. D'autant qu'il ne faut pas 
compter sur les fournisseurs de solutions clouds pour attirer votre 
attention sur ces points ! En fait, les fournisseurs ne vont discuter 
GDPR que si vous leur en parlés et abordés les questions techniques à ce 
sujet. Sinons... silence radio et on laisse l'hébergeur faire ce qu'il 
veut. Sans compter que les département légaux des entreprises ne sont 
souvent pas à la page en ce qui concerne le cloud et ses implications; 
et je ne parle même pas des département chargés de négocier les 
contrats. Pour une grande majorité, la notion de SLA (Servive Level 
Agreement) ne fait même pas partie du contrat...



(enfin bon, comme d'hab je m'écarte fortement du sujet initial, désolé ^^)


Oui, j'avoue être aussi coupable.


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-26 Par sujet felix 
On Wed, Nov 25, 2020 at 05:18:34PM +0100, Frédéric Dumas wrote:
> > veuillez noter que la suppression des données de votre profil est 
> > définitive et irréversible.
> 
> veut dire qu’ils vont effacer mes données personnelles de leurs bases, 
> ou veut dire qu’ils vont supprimer mes données personnelles de 
> l’affichage sur leur site web (les conservant en réalité sans m’y 
> donner accès, pour les seuls besoin du data mining)?

Très bonne question!

Les réponses déjà postées suggérant de demander à obtenir TES données,
avant de demander à les supprimer et te désinscrire sont correctes...

> Celui qui clique sur « supprimer mon profil » ne fait-il pas en fait 
> une fausse manoeuvre, ne lui faudrait-il pas mieux demander la 
> suppression des données le concernant au titre de la RGPD ?
Donc oui.

> Comment faites-vous personnellement ?

Je n'ai jamais fait, mais je connaissais Web 2.0 Suicide Machine:
  https://en.wikipedia.org/wiki/Web_2.0_Suicide_Machine
  http://suicidemachine.org/

-- 
 Félix Hauri  --  http://www.f-hauri.ch
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-26 Par sujet Arnaud 
Le 26.11.20 à 08:44, Daniel Cordey a écrit :
> 
> On 26.11.20 05:29, Laurent Franceschetti wrote:
>> Est-ce que ma compréhension sur les buts du « libre », et sur l’évolution de 
>> notre mission. correspond à la vôtre ?
>>
> Oui, oui, je partage :-)

Bah je dirais que ça va dans le sens de toutes les aberrations de notre époque.

Tout comme on nous pousse coûte que coûte à utiliser un smartphone...
Tout comme on nous pousse à utiliser Zoom dernièrement, sinon pas de formation 
etc., et on est écarté de plus en plus de la société...

Il y a pourtant des équivalents, même infomaniak propose kmeet. 
Mais avancer les équivalences, par expérience, fait de nous quelqu'un qui 
semble embêter les gens dans leurs solutions de facilité.
(on a ça en place, si vous êtes pas content, et bah tant pis pour vous)

Après faut voir, car le cloud ça peut devenir intéressant dans le futur. Par 
exemple:
https://www.zdnet.com/article/aws-outage-impacts-thousands-of-online-services/

Pour moi, les solutions non cloud qui avaient un certain impact lors de 
défaillances, 
sont remplacées par des solutions qui ont encore plus d'impact lors de 
défaillances.

Ca va sûrement s'améliorer, ce genre d'évènements va indiquer qu'il faut des 
solutions de repli pour éviter ce genre de cas.
Même certains projets opensource ont des instances AWS ou autres...

(enfin bon, comme d'hab je m'écarte fortement du sujet initial, désolé ^^)


OpenPGP_0xEA0DA251B671CC2A.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-25 Par sujet Daniel Cordey 


On 26.11.20 05:29, Laurent Franceschetti wrote:

Est-ce que ma compréhension sur les buts du « libre », et sur l’évolution de 
notre mission. correspond à la vôtre ?


Oui, oui, je partage :-)


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-25 Par sujet Laurent Franceschetti 
C’est un domaine que je connais moins, mais il me paraît effectivement 
important de conserver des compétences dans ce domaine (donc de savoir 
installer des parcs de machines « bare metal », avec des méthodes 
industrielles). Pour ma part, je suis assez curieux à propos de Ansible : je 
trouve que l’idée est originale et assez puissante. 

Et ce, toujours dans une perspective d’une alternative aux GAFAM. À la fin des 
années 1970, on a été préoccupé par le monopole d’IBM sur le matériel; ensuite, 
dans les années 1990, de Microsoft sur le logiciel; aujourd’hui des GAFAM sur 
le cloud. On dirait que la menace du monopople persiste, mais qu’elle change 
perpétuellement de forme.  Et la réponse a toujours été la même: les standards 
ouverts, l’esprit de corps de la communauté, et… l’âme de chaque 
non-conformiste qui refuse de laisser les choses aller au diable.

Donc l’enjeu du présent ne serait plus uniquement le FLOSS 
(Free-Libre-and-Open-Source-Software) mais le « FLOSC » (…-Cloud) ?

Est-ce que ma compréhension sur les buts du « libre », et sur l’évolution de 
notre mission. correspond à la vôtre ?



> Le 25 nov. 2020 à 22:14, Arnaud  a écrit :
> 
> Le 25.11.20 à 22:03, Laurent Franceschetti a écrit :
>> Ah oui, ça c’est le top ! Après c’est une question de 
>> coût(effort)/opportunité… Car des services partagés sur des centres 
>> d’hébergement sont vraiment très bon marché.. Mais ça serait la solution de 
>> repli ultime...
> 
> De nos jours, d'après ce que j'ai vu, et par expérience, les coîts ne sont 
> pas si élevés que ça.
> Mais c'est clair que comparé à un hébergement chez un fournisseur, il faut 
> comparer (redondance électrique, connexion, etc.)
> 
> Mais je me forme à l'AI, le cloud computing, et à la gestion de machines par 
> k0s/k3s/k8s, openshift/openstack, ansible et autres,
> alors cette installation a plusieurs raisons d'exister.
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-25 Par sujet Arnaud 
Le 25.11.20 à 22:03, Laurent Franceschetti a écrit :
> Ah oui, ça c’est le top ! Après c’est une question de 
> coût(effort)/opportunité… Car des services partagés sur des centres 
> d’hébergement sont vraiment très bon marché.. Mais ça serait la solution de 
> repli ultime...

De nos jours, d'après ce que j'ai vu, et par expérience, les coîts ne sont pas 
si élevés que ça.
Mais c'est clair que comparé à un hébergement chez un fournisseur, il faut 
comparer (redondance électrique, connexion, etc.)

Mais je me forme à l'AI, le cloud computing, et à la gestion de machines par 
k0s/k3s/k8s, openshift/openstack, ansible et autres,
alors cette installation a plusieurs raisons d'exister.



OpenPGP_0xEA0DA251B671CC2A.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-25 Par sujet Laurent Franceschetti 
Ah oui, ça c’est le top ! Après c’est une question de coût(effort)/opportunité… 
Car des services partagés sur des centres d’hébergement sont vraiment très bon 
marché.. Mais ça serait la solution de repli ultime...



> Le 25 nov. 2020 à 21:57, Arnaud  a écrit :
> 
> Le 25.11.20 à 21:36, Laurent Franceschetti a écrit :
>> Perso, je pense qu'une voie à suivre serait «  l’auto-hébergement facilité » 
>> (c’est-à-dire que des hébergeurs fournissent une installation « clé en main 
>> » d’applications Open Source). Je connais un peu mieux Infomaniak, et je 
>> sais qu’ils ont fait des efforts dans ce sens (en tout cas avec les applis 
>> PHP comme WordPress et nextcloud). Je pense aussi qu’il y a d’autres 
>> hébergeurs qui font ça ?
> 
> Personnellement, je suis en train de créer mon propre cloud personnel, 
> auto-hébergé chez moi :)
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-25 Par sujet Arnaud 
Le 25.11.20 à 21:36, Laurent Franceschetti a écrit :
> Perso, je pense qu'une voie à suivre serait «  l’auto-hébergement facilité » 
> (c’est-à-dire que des hébergeurs fournissent une installation « clé en main » 
> d’applications Open Source). Je connais un peu mieux Infomaniak, et je sais 
> qu’ils ont fait des efforts dans ce sens (en tout cas avec les applis PHP 
> comme WordPress et nextcloud). Je pense aussi qu’il y a d’autres hébergeurs 
> qui font ça ?

Personnellement, je suis en train de créer mon propre cloud personnel, 
auto-hébergé chez moi :)


OpenPGP_0xEA0DA251B671CC2A.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-25 Par sujet Arnaud 
Le 25.11.20 à 17:41, Laurent Franceschetti a écrit :
> Communications: Whatsapp à la poubelle, remplacé par Signal 
>  (et pour la boîte c’est du rocket.chat 
>  auto-hébergé, c’est du tonnerre).  Mon réseau de 
> contacts est en train de passer progressivement à Signal.

Signal j'ai essayé de m'y intéresser, mais pour fedora, c'est soit flat, soit 
snap, ou un dépot copr il semblerait, 
donc je me suis dit que je n'avais pas tellement besoin de ça actuellement.

Sinon, j'ai appris l'existence d'une entreprise dans le domaine de 
l'informatique qui se situe à moins de 500 mêtres de chez moi par les réseaux 
sociaux,
et ils indiquent qu'ils prennent très au sérieux la RGPD, fournissent un numéro 
de téléphone si on veut avoir plus d'informations à ce sujet,
que j'ai appelé, mais aucune des 3 personnes que j'ai eu à travers leurs 
services, ne semblaient savoir ce qu'était la RGPD.





OpenPGP_0xEA0DA251B671CC2A.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-25 Par sujet Laurent Franceschetti 
> 
> Le 25 nov. 2020 à 21:01, Daniel Cordey  a écrit :

> Bonne initiative ! J'essaie aussi de passer à Signal, mais plein de mes 
> contacts ne suivent pas vraiment, hélas.
> 


Pour ma part, j’ai eu pas mal de succès à faire migrer des non-informaticiens 
autour de moi sur Signal. Notamment des gens qui se sentaient mal à l’aise avec 
Facebook ou ce genre d’outils et qui sont sensibles aux arguments sur la 
sécurité. D’autant plus que l’appli s’est bien améliorée.

J’ai vu que cela payait d’y aller « franco » et d’expliquer les vraies raisons 
autour de soi, tout en restant compréhensible. Ceci est facilité, en ce moment, 
c’est que la confiance dans les GAFAM n’est pas très élevée en ce moment dans 
l’opinion publique. Surtout avec les discussions autour de la censure, qui ont 
été particulièrement vives dernièrement. Les gens ont besoin de changement, 
donc ça pourrait être bon pour le « libre et open source »… pour autant qu’on 
étende la définition , pour qu’elle inclue aussi les services en ligne. 

Perso, je pense qu'une voie à suivre serait «  l’auto-hébergement facilité » 
(c’est-à-dire que des hébergeurs fournissent une installation « clé en main » 
d’applications Open Source). Je connais un peu mieux Infomaniak, et je sais 
qu’ils ont fait des efforts dans ce sens (en tout cas avec les applis PHP comme 
WordPress et nextcloud). Je pense aussi qu’il y a d’autres hébergeurs qui font 
ça ?

Pour ceux qui se souviennent des distro Linux au milieu des années 1990, 
c’était assez sportif… maintenant c’est quasiment devenu du « presse-bouton ». 
Est-ce qu’on va arriver à ce genre de services, mais pour des applications « 
serveur » clé en main, auto-hébergées, pour des chats, des blogs, des wikis ? 
Des sortes de "distros" dans le cloud pour petits entreprises, associations ou 
particuliers ? 
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-25 Par sujet Daniel Cordey 


On 25.11.20 17:41, Laurent Franceschetti wrote:

Très intéressé par toutes les idées, démarches qui vont dans ce sens.

Bonne initiative ! J'essaie aussi de passer à Signal, mais plein de mes 
contacts ne suivent pas vraiment, hélas.


Je n'utilise que whatsapp et gmail (mais seulement quand je ne peux pas 
faire autrement). Sinon, j'ai bien un compte FB mais que je n'utilise 
plus depuis plus de 10 ans. Je le laisse là pour éviter que quelq'un ne 
crée un compte à mon nom. J'ai surtout remarqué que le flux de détrituts 
issus de FB a cessé du jour au lendemain lorsque j'ai installé un 
bloqueur d'adresse dans mon navigateur. Il y avait une extension Chrome 
gratuite qui fonctionnait bien, mais elle est devenu payante. Je refuse 
de payer pour bloquer des choses que je ne veux pas... Je vais donc sans 
doute bloquer ça au niveau d'un de mes firewalls...


dc

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

2020-11-25 Par sujet Laurent Franceschetti 
Sur le principe, il faudrait leur demander avant de… te désincrire :-) Donc 
ouvre un ticket auprès de leur service client et tu leurs demandes. La même 
RGPD, sauf erreur, exige qu’ils soient capables de te livrer ta propre 
propriété intellectuelle.

Voici un site qui explique les démarches:
https://demarchesadministratives.fr/demarches/comment-recuperer-ses-donnees-personnelles-collectees-par-les-reseaux-sociaux
 



Et bravo pour l’initiative de se désincrire de réseaux sociaux « GAFAM ». Cela 
fait un moment que je me disais que ce serait sérieusement le moment de se 
désintoxiquer des médias de masse (télé, radio). Jusqu’à ce que je me rende 
bien compte que ces réseaux sociaux constituaient une autre forme de défonce et 
qu’après on est trop à leur merci (ce qu’on a le droit de voir ou ne pas voir, 
le droit de dire ou ne pas dire…). 

Du coup, c’est la cure de désintoxication !

L’idée, c’est de faire la même démarche qu’on a faite pour le Logiciel Libre, 
mais face aux gros réseaux sociaux: tout remplacer par de l’auto-géré (Open 
Source), auto-hébergé, ou quelque chose qui s’en rapproche. 

Communications: Whatsapp à la poubelle, remplacé par Signal 
 (et pour la boîte c’est du rocket.chat 
 auto-hébergé, c’est du tonnerre).  Mon réseau de 
contacts est en train de passer progressivement à Signal.
J’ai monté mon propre blog cousu main en static html (avec Mkdocs-Material 
 mkdocs-macros 
); avec un « manifeste 
» pour expliquer la démarche 
).
Je redécouvre les joies du RSS/atom… Pour l’expérience, je trouve Raven 
(desktop app, Open Source) assez moyen et limité; par contre l’extension 
Feedbro Reader  
de Firefox est respectable (la présentation fait encore un peu « années 2000 », 
mais ça s’améliore si on passe en mode « dark »).

L’idée n’est pas forcément de convertir tout le monde (pas plus qu’on a 
converti tout le monde à Linux ou à l’Open Source); mais de se reconquérir 
notre propre espace de liberté. Et c’est le bon moment, car j’ai senti, dans 
les dernières semaines, un gros ras-le-bol de pas mal de contacts 
non-informaticiens, qui veulent eux aussi du changement.

Très intéressé par toutes les idées, démarches qui vont dans ce sens.

Bonne soirée,
Laurent




> Le 25 nov. 2020 à 17:18, Frédéric Dumas  a écrit :
> 
> 
> Avant de cliquer sur « supprimer mon profil » sur un réseau social, je 
> voulais demander conseil ici, même si le sujet n’est pas strictement logiciel.
> 
> Le marketing « digital » est tellement habile à nous empapaouter, qu’on finit 
> par se méfier même des messages les moins ambigus. Est-ce que le message 
> suivant :
> 
>> veuillez noter que la suppression des données de votre profil est définitive 
>> et irréversible.
> 
> veut dire qu’ils vont effacer mes données personnelles de leurs bases, ou 
> veut dire qu’ils vont supprimer mes données personnelles de l’affichage sur 
> leur site web (les conservant en réalité sans m’y donner accès, pour les 
> seuls besoin du data mining)?
> 
> Celui qui clique sur « supprimer mon profil » ne fait-il pas en fait une 
> fausse manoeuvre, ne lui faudrait-il pas mieux demander la suppression des 
> données le concernant au titre de la RGPD ?
> 
> Le réseau dont il s’agit ici est Xing.
> 
> Comment faites-vous personnellement ?
> 
> Merci.
> 
> 
> PS: on évitera s’il vous plait les réponses telles que: « il suffisait 
> simplement de ne pas t’inscrire... ».
> 
> --
> Frédéric Dumas
> f.du...@ellis.siteparc.fr
> 
> 
> 
> 
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull