ghusson a écrit 168 commentaires

Merci d'avoir pris le temps de me lire :-)
J’essaye de faire des explications claires mais ça prends plus de caractères :-)

Auto-enregistrement : on regardera ça de près
UMA : bien sympathique, je me suis cramé des neurones, ça va peut être nous servir.

Merci pour tes retours !

Merci d'avoir répondu si rapidement et merci pour ton aide !

Mais encore? Plus précisément qui échange avec qui?

J'aurais dû donner plus de détails désolé.
La on réfléchit en terme d'applications qui discutent à travers une architecture fédérée (ni centralisée, ni pair à pair). On voudrait garder le même avantage que XMPP : ne pas avoir à configurer quoi que ce soit pour que les applications puissent discuter entre elles. Et c'est le cas avec notre POC puisque nos applications utilisent le protocole XMPP.
On sort le cas de l'IoT et de l'acquisition de données de l'équation pour le moment (mais on garde ça dans un coin de notre tête).

Scénario complexe (car tripartite) :
- l'appli A possède des données de courbes de charges d'énergie.
- l'utilisateur final a un compte sur une appli C qui permet d'afficher de jolies courbes sur une GUI WEB
- l'appli C utilise une appli B pour récolter les données de l'appli A, les stocker et les traiter (ex : fournir à la demande des jeux de données minimaux à l'appli C pour afficher un graphe entre telle date et telle date, autre exemple : envoyer une alerte à l'appli B quand il n'y a plus du tout de consommation électrique dans un cas de coupure de disjoncteur différentiel par exemple)
Un scénario plus simple serait que l'appli C fasse le boulot de l'appli B elle même, et ce sera possible techniquement. Mais on ne s'empêche pas d'avoir des relations multiple. L'idée finale est de pouvoir faire en sorte qu'une appli ait accès à N jeux de données de N applications ET d'avoir un chaînage avec N applications pour pouvoir créer ou répondre à de nouveaux usages avec des données multiples.
Un exemple concret du POC est expliqué p10 du rapport de conclusion du POC (voir : rapport_conclusion.pdf). La figure 1 représente des échanges entre applications. Les applications n'ayant pas été prévus pour se "brancher" directement en fédération, nous avons ajouté des composants d'interface que l'on a appelé "proxy de données"

Quel est l'impact du RGPD dans ton cas?

Nous avons fait une étude non experte sur le RGPD appliqué au cadre d'une architecture fédérée. Voir : Rapport-RGPD.pdf. Ce qu'il en ressort c'est que l'on a tout intérêt à prévoir des mécanismes les plus automatisés possibles pour aider les applications à être en conformité (voir les encadrés "recommandations" dans le rapport). Ce que l'on a vu également c'est que le lien contractuel (ou non) joue beaucoup sur les responsabilités entre applications qui échangent des données. Un appli (et donc un organisme) peut être considérée comme co-traitante, sous-traitante ou indépendante. Nous allons contacter la CNIL et/ou le Pôle d'excellence cyber de Bretagne pour avoir des éclaircissements sur le sujet.

Chaque application est connue du serveur OAuth2 par un identifiant/mot de passe.

Du coup, ce paradigme n'est pas souhaitable. Le besoin c'est de faire de l'autorisation avec un serveur "que l'on ne connaît pas encore". Le but étant que les utilisateurs donnent leur consentement pour tout échange/traitement de données. Dans le scénario complexe exposé ci-dessus, l'utilisateur donne son consentement dans l'appli C (GUI WEB) pour que cette dernière traite/affiche ses données. Puis on imagine que l'appli C va utiliser Oauth2 ou OIDC avec l'appli A (source des données). Mais après, l'appli B doit avoir le consentement de l'utilisateur pour aller chercher les données de l'appli A… Et tout ça sans configuration préalable (sauf à avoir une sorte de catalogue central, chose que l'on aimerait éviter car on ne veut pas ajouter une composante centralisée…). Et c'est là que je ne vois pas comment y arriver.
Nous avons regardé oAuth2 et nous avons implémenté la partie "client" pour récupérer des données auprès d'une application du type A justement :-) Et je pense que je vais devoir potasser sérieusement avant d'aller plus loin. Tu aurais des documentations à me conseiller ou c'est préférable que j'aille voir directement aux sources :
- https://openid.net/connect/
- https://tools.ietf.org/html/rfc6749

PS : j'ai déterré ça : https://linuxfr.org/news/authentifiez-vous-sans-mot-de-passe-grace-a-xmpp, ça va peut être m'intéresser pour les authentifications entre applis…

Bonjour,

Intro :
Je travaille en tant que professionnel sur le projet SEN2, la suite du projet SEN1 (voir : https://github.com/consometers/sen1-poc-docs) et en tant que bénévole dans le collectif des Consometers (voir https://wiki.consometers.org/doku.php).
On travaille sur l'échange de données énergétiques (et plus) en mode fédéré. Nous avons fait un POC en nous basant sur le protocole XMPP. Nous avons eu à utiliser Oauth2 pour l'autorisation de récupération des données de compteurs connectés.

Réflexions :
Pendant ce POC, nous avons réfléchi au RGPD et à comment fournir une base de services d'infra qui simplifie le travail d'implémentation d'un nœud dans la fédération. Une des solutions retenue est l'autorisation décentralisée, via des protocoles comme Oauth2 ou OIDC. MAIS ces protocoles nécessitent des paramètres amont (ex : URL du fournisseur de données pour la demande d'autorisation).

Question :
On commence à peine à s'y mettre et on est loin d'être expert dans le domaine de la SSO et de l'autorisation décentralisée. Mais à l'instar de XMPP, y aurait il une méthode infrastructurelle qui permettrait de nous affranchir d'un paramétrage spécifique pour chaque service dont l'autorisation est nécessaire ? Je m'explique, pour XMPP, on envoie un message à plop@superweb.org. Le client envoie le message au serveur. Le serveur cherche l'entrée SRV du domaine superweb.org correspondant au service XMPP. Le serveur XMPP se connecte sur le serveur du domaine superweb.org et lui transfert le message.
Est-ce qu'il y aurait déjà une méthode de ce type pour OIDC ou Oauth2 ? Si non, est ce que ce serait pertinent d'en créer une ?
Nous voulons faire sen sorte que les échanges de données entre applications soient fluides, nous voulons tracer les autorisations, et tout ça dans un mode fédéré. Merci d'avance pour vos avis éclairés !

PS : merci de partager ton projet !

C'est une charte rédigée dans un contexte précis à l'origine. Mais son utilisation peut être bien plus large. Cette charte est valable pour tout projet informatique, issu de n'importe qui.
La version actuelle est jeune, peut être naïve.
N'hésitez pas à donner des conseils :-)

Ce document n'est pas technique et s'adresse aux organismes voulant se doter d'un système de type IoT ou de "ville intelligente". Il permet une acculturation sur le logiciel libre et ses avantages dans ce contexte.

Ce document n'est pas technique et s'adresse aux organismes voulant se doter d'un système de datalogging de bâtiment ou de supervision énergétiques. Il permet une acculturation sur le logiciel libre et ses avantages dans le contexte du datalogging.

Merci pour les infos et ta sollicitude :-). Pour la partie github, j'avais la même vision.
ADULLACT, c'est pas bête du tout. Ça reste la référence pour les clients de l'administration française. Je vais réfléchir à ça.
Mais bon, la clientèle future n'étant pas que du domaine de l'administration, ça va certainement se finir sur github :-)

Idem ici.
Un problème de cache navigateur peut être ?

D'une professeur (donc de sexe féminin) de C en école d'ingé… véridique, involontaire et inopiné :
"Il n'est pas très aisé de travailler avec un String !"
=> LOL, repris par le canard de l'école, mythique :-)

Sinon, essayez de représenter 132 en binaire sur vos main (et oui, on peut compter jusque 1023 avec 10 doigts)… Il y a seulement 10 types de personnes dans le monde, tout ça… Et bonne année 2017 au passage ! :-)

Pour information ou pour ceux qui n'auraient pas fait attention, une doc officielle est sortie il y a peu (moins de 6 mois). En effet, PVE est maintenant bien étoffé, la virtualisation KVM se complexifie par les nombreuses option proposées (ex : NUMA). Du coup, une bonne doc efficace a été réalisée : http://pve.proxmox.com/pve-docs/. Bonne lecture :-)

Je n'ai pas encore testé cette fonctionnalité mais la roadmap précise que ce n'est qu'en CLI que l'on peut en profiter pour le moment (voir http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.4).
C'est quelque chose que j'attendais car migrer à chaud un serveur avec 64Go de RAM sur le réseau d'administration (1Gb/s en général) ça peut prendre du temps… minimum 10mn :-)

Oui, vous reprendrez bien un petit coup de Proxmox 500mg avec votre infrastructure de virtualisation ?
Effectivement, ça "juste marche", à part quelques rares exceptions (notamment au moment du passage à la v4, voir mes posts sur le forum PVE à l'époque).
A chaque fois que j'ai montré PVE (Proxmox Virtual Environment) ou PMG (Proxmox Mail Gateway) à un admin sys, il a essayé et y est passé :-)

La seule fonctionnalité manquante par rapport à un VMWARE c'est l'orchestration automatique (l'infra de virtualisation migre automatiquement les VMs en fonction des ressources à dispo sur les noeuds). Personnellement c'est une fonctionnalité que je n'ai jamais souhaité. Quelqu'un a t'il une expérience où l'orchestration automatique est indispensable ?

Pour information je suis partenaire revendeur Proxmox (Liberasys, dans le Morbihan) et expert PVE (Proxmox Virtual Environment). A ce titre je revend les services Proxmox avec une marge et j'assure le niveau 1 et 2 (Proxmox assure le niveau 3).

Proxmox propose plusieurs formules depuis déjà quelques années.
Pour information, il n'y a pas de licence. C'est un système de souscription de service. Le plus bas niveau (formule COMMUNITY) est l'accès au repository entreprise. Cela vaut le coup pour la tranquillité. Je m'explique :
1. Il y a un repository libre qui contient les dernières versions des paquets PVE, mais qui ne sont pas validés "ready for production".
2. Proxmox propose un repository entreprise, avec des versions de paquets testées sur leur infrastructure dédiée aux tests de validation.
Proxmox conseille de ne pas utiliser le repository libre en production (voir : https://pve.proxmox.com/wiki/Package_Repositories).

La formule COMMUNITY permet donc la tranquillité d'esprit (paquets approuvés "ready for production" par Proxmox), mais n'inclue pas de service de support. Par ailleurs, dans tous les cas il y a quand même le support communautaire via le forum.
Ensuite, en payant plus cher, il y a d'autres formules qui donnent accès au support, avec différents niveaux de service (notamment par le biais de tickets). Cela va jusqu'à ce que l'équipe support de Proxmox se connecte à votre équipement pour diagnostiquer et réparer (en passant, pensez au reverse tunnel SSH avec une machine tierce utilisée comme un tiers de confiance). Pour plus d'information, voir ici : http://www.proxmox.com/en/proxmox-ve/pricing

J'ai suivi PVE dès 2008, je l'utilise en production depuis 2009. Ce produit se bonifie avec le temps et j'aime les décisions de Martin MAURER et de son frêre Dietmar. Cette année je suis par exemple intervenu pour un client qui va migrer 400 serveurs physiques sur moins de 30 noeuds PVE. Après une phase de tests préliminaire, ils étaient très satisfaits et ont poursuivi pour la qualité, la robustesse, la simplicité, et le coût total de possession du produit sur le long terme. De plus ils sont très contents de maîtriser leur solution de virtualisation (PVE est libre, basé sur des briques libres, sur la distribution Debian, voir ici pour le code source : https://git.proxmox.com/).

Par ailleurs, et pour information, leur solution Proxmox Mail Gateway, est une très bonne solution antispam/antivirus et bien plus encore. Elle vaut le détour, quoiqu'un peu cher aux yeux de certains. Mais c'est là encore c'est le prix de la tranquillité :-) Alors oui, j'entends déjà "ça pue c'est pas libre", mais les briques de base sont archi connues et c'est tellement bon d'avoir la main sur une Debian pour une bonne solution d'antispam… :-)

Si la règle 4 s'applique alors qu'elle ne devrait pas, c'est qu'ils l'ont fait exprès chez Ubuntu, ou que la version de systemd utilisée fait autrement (v229).

Parce que je dois faire tourner ma boite :-) Tout ne peut pas toujours être parfait… (je me rends compte et j'accepte cela de plus en plus en étant "patron" :-).
Un investissement peut se faire en plusieurs phases, voir doit se faire en plusieurs phases selon les cas et les stratégies.
La, présentement, je n'ai pas 5 jours dispos pour me mettre plus sérieusement à git.

Ah ben ça alors… aussi libre que OPEN-V ???
Je ne l'avais pas vu passer celui la !
Après ce n'est peut être pas aussi porteur qu'un coeur RISC-V ?
(ça fait des années que je veux essayer un parallax… pour le côté multi-coeur du µC… ahhh si j'avais le temps :-p)

Merci pour les infos.
En tout cas, de ce que j'ai vu rapidement sur Internet, on ne simule pas physiquement la puce (au niveau interactions physiques entre les transistors). Par contre on le fait en terme de lignes de données / timing / execution de code. Exemple : https://sourceforge.net/projects/pvsim/. Au passage, j'ai vu passé plusieurs outils de simulation pour Verilog.

J'ai commencé à bidouiller solaris et linux en PXE sur une station Sparc 5… processeur RISC en 2002.
A l'époque, on ne savait pas "qui allait gagner" entre RISC et CISC.
Aujourd'hui, c'est pareil :-) C'est juste qu'on commence à avoir une meilleure idée de dans quel cas utiliser l'un ou l'autre.
En architecture des microprocesseurs ça a tendance à bouger ces dernières années. Que va donner RISC + GPU détournée ou RISC + FPGA intégré ? Quelle évolution les processeurs libres vont ils amener ?

Affiche les adresses de la carte réseau (qui n'est pas eth0 parce que le nommage a changé avec Ubuntu Wily).
Je confirme, j'ai installé mon poste de travail en Ubuntu 16.04.1 dernièrement (avant j'étais sous Debian).
Et "enx" suivi de 12 caractères hexadécimaux ça pique un peu pour l'interface Ethernet du dock… :-p

http://www.journaldugeek.com/2014/03/26/si-cest-gratuit-vous-etes-le-produit/

De ce que je comprends :
- VHDL simule le processeur au niveau physique ?
- Verilog permet de compiler une structure de transistors, de l'appliquer sur un FPGA mais pas de simuler son fonctionnement physique ?

Désolé :-)

Il y a même aucune ligne de code VHDL dans le lien donné puisque c'est du Verilog ;)

Ah, bon ben voila, merci de me sortir de mon obscurantisme ;p

500 lignes pour une ALU c'est bon ? Je m'attendais vraiment pas à ça.

Une autre question en passant : le code verilog, on peut l'utiliser pour simuler la puce ? Y a t'il des logiciels open-source pour le faire ? Y a t'il besoin de bibliothèques non libres ?

Merci pour le conseil. Voila ce qui va se passer (voir websérie " Les visiteurs du futur") :
- je vais faire comme ça pour le moment
- ça va merder
- je lirai la doc
- ça me donnera envie d'installer un gitlab
En attendant, j'ai un repo au lieu d'un répertoire non versionné.
Voir commentaire bookmark pour partager les liens, ça me servira dans quelques mois ;p

Ce journal montre comment se mettre vite fait à git et peut être pas de la bonne manière.
Je propose aux connaisseurs de partager ici des URLs qui expliquent comment bien utiliser git.
Merci pour tout vos retours.

Commencer par lire la doc ici : https://git-scm.com/book/fr/v2
Pour un serveur auto-hébergé, voir ici : https://about.gitlab.com/products/