A moins que je n'ai pas compris ton idée, pour moi ce n'est pas nécessaire.
Il y a 1 seul autossh par OS client.
Après pour l'environment file, pourquoi pas. Normalement la bonne pratique serait un fichier /etc/default/autossh_zabbix par exemple. Mais pour ce cas j'ai voulu quelque chose de simple et d'autoporteur. A améliorer avant déploiement massif.
Pour le %i j'ai rencontré ça avec getty. Tiens je vais faire un journal :-) J'ai un peu galérer pour la sonsole sur port série ;p
Je ne comprends pas bien le sens de ta question.
J'utilise cette méthodo : variables, template, sed parce que pour le moment je ne me suis pas mis à des moteurs de templating ou d'industrialisation de déploiement / gestion de conf. Donc pour moi c'est le bon moyen de séparer les choses en attendant mieux (Ansible / Salt). Avec cette méthode (cat/sed) je ne suis pas embêté avec les problèmes de caractères d'escaping dans les variables bash.
Je comprends tout à fait ton point de vue. Et je n'ai pas finalisé le tout. Saches que :
1) c'est un hack pour chiffrer le protocole de zabbix, bien que la gateway de reverse SSH soit intéressante fonctionnellement
2) les services tournent sur les OS clients (donc 1 seul service par OS, pas 100 sur un)
3) pour faire propre, il faudrait soit un système de déploiement automatique type Ansible, soit faire un paquet, soit packager un minimum et en effet sortir la conf
4) il doit y avoir une corrélation entre l'ID zabbix, l'ID du tunnel et donc les ports
Bref, c'est loin d'être fini pour une mise en production massive et parfait. Mais en attendant ça fait bien le job.
Après en documentant, ce système reste simple et efficace donc pas cher à mettre en œuvre, si il y a peu de noeuds distants. Tu connais la loi des 80/20 ? Il faut rester rentable. Et je pense qu'avec un petit coup d'Ansible ça va le faire :-)
Après sur la question de la doc, c'est toujours pareil, l'admin qui ne documente pas suffisamment afin qu'il (ou la société qui l'emploie) puisse être tranquille si du jour au lendemain il n'est plus dans la boite (vacances, maladies, quoi que ce soit), est un mauvais admin. Ou alors il n'a pas su convaincre sa hiérarchie de l'intérêt de documenter.
Au sujet de ta notion de wrapper, pourquoi pas. Mais il est lancé par quoi ? rc.local ? Je ne suis pas d'accord. Systemd a été choisi par Debian. Il a son rôle. Il faut l'utiliser (lancer, maintenir, renvoyer l'état, gérer les services/démons). Ok, il faut faire l'effort de lire la doc. Mais tu utilises toujours ifconfig ou tu es passé à ip link/addr/route ? :-)
Personnellement je considère autossh comme le démon. Le bash autour n'est la que pour gérer le lancement du démon et les variables. Et systemd gère le service.
Après pour le déploiement, la configuration, ce serait en effet plus judicieux d'utiliser un système comme Ansible par exemple. Mais ça ne change pas la base de la solution :-)
Qu'est ce que tu reproches au fait que j'utilise systemd pour gérer un service ? Moi ça me paraît naturel.
En relisant, j'ai laissé traîner des droits abusifs pour le fichier, qui devraient être en 644 au lieu de 755 (si un gentil modérateur passe par la…). Après, je ne sais pas si je fais tout bien avec systemd (wantedby) mais le fait est que ça fonctionne.
Personnellement j'utilise zabbix depuis 2009. J'ai développé des scipts d’auto-découverte pour linux qui me permettent de déployer très vite la supervision des nouveaux serveurs (voir ici : https://share.zabbix.com/operating-systems/linux-autodiscovery-disks-proces-tcp-udp-service).
Zabbix a mis en place un site (béta) d'échange : https://share.zabbix.com/ ce qui est bien bien pratique.
De plus la V3 va permettre les communications chiffrées, ce qui va me permettre d'enfin utiliser les commandes à distance (ex : prendre un ps, iotop, atop de la machine en cas de dépassement de métriques).
Ça me fait plaisir de voir ça. J'y avais pensé mais je n'ai pas pris le temps de tester :-)
Merci pour le partage !
Après pour optimiser l'empreinte, il est possible de ne prendre que les binaires et les librairies nécessaires (via un script d'automatisation qui cible des binaires définis). J'avais déjà fait ça pour un système de backup à chaud qui créait un ré-installeur sur USB dans un job précédent. Les scripts de bases sont présents sur le net.
Concernant ton besoin, il y a elgg qui peut coller. solution de type réseau social d'entreprise (très simple et modulaire).
Je l'ai mis en test pour le CREPP (asso type hackerspace à Lorient). Il est en jachères depuis quelques mois avant packaging et lancement mais ça te donnera une idée. Et il y a un module de vote pour info :-)
elgg : https://elgg.org/
site de mon asso : http://fil.crepp.org
Après, je peux faire des prestation par ma boite Liberasys. Mais apparemment, de gentils administrateurs sont prêt à vous aider bénévolement, donc c'est super !
Bonjour,
Désolé je n'ai pas lu avec attention tout ton article. A "négation de l’altérité" j'ai décroché et à "manichéisme boulimique" tu m'as définitivement perdu. Je pense que ton analyse n'est pas dénuée de sens. Malgré cela, je lis linuxfr.org depuis de nombreuses années (2009 si je me souviens bien). Et c'est une de mes sources de veille technologique pour l'open source et le logiciel libre. J'ai créé ma société en 2015 et j'ai décidé de contribuer. Résultat : exactement ce à quoi je m'attendais :-)
Des commentaires de plusieurs ordres :
- objectifs, ou subjectif et acerbes : faisant avancer la réflexion et développer notre champ de connaissance (ceux la je les préfère),
- des remerciement (ça fait toujours plaisir de voir que son travail sert à quelque chose et qu'il est apprécié),
- pourquoi avoir fait ça (c'est quoi l’intérêt) : des membres qui n'ont pas la même vision ou le même champ d’application ou qui ont eu l'information ailleurs (soit je transmet une information soit j'en reçoit une - ex : ah, oui quelqu'un l'avait déjà fait… pourquoi je me suis embêté pour rien :-),
- hors sujet : non lié au sujet, un ovni quoi (l'auteur a certainement lu de travers ou veut vite fait partager une expérience, mais ça tombe à l'eau),
- insulte : je n'ai pas encore eu :p (mais à éviter).
Après, il faut bien réaliser que les membres postent souvent vite fait sans se soucier des formes… Ce qui conduit à une montée en pression des commentaires. Mais ce n'est pas nouveau… dans les milieux de passionnés, surtout sur internet, ça arrive régulièrement (c'est pour cela qu'on a inventé les points Godwin ;-) Les mots ne représente que 7% d'un message alors imagine les incompréhensions, les quiproquos, les sentiments d'injustice, etc. C'est pour cela qu'il faut se retenir de poster des commentaires "à chaud", sans réflexion préalable et sans un minimum de forme. Mais personnellement, je préfère avoir des commentaires quels qu'ils soient plutôt qu'un grand vide :-) En effet, un commentaire c'est quelqu'un qui prends le temps d'écrire une réaction, une réflexion, une information… et ça a de la valeur.
Pour conclure, je trouve que tu juges beaucoup. Pour ma part, je pense qu'avant de juger il faut connaître et quand on connaît, on a plus envie de juger. Ici on est entre connaisseurs du monde open source et du libre. On est des passionnés. Si il n'y avait pas de discussions enflammées, de un on se ferait ch*** et de deux tu trouverais ça normal ? ;p
Là on aborde la problématique côté FAI et client final de type particulier. Il y a aussi les entreprises. Et pour celles ci, il y en plus les problèmes de sécurité lié à IPv6. Pour un aperçu, je vous propose ce podcast : https://www.nolimitsecu.fr/ipv6/
Les licences de logiciel libre qu'il est possible de viser dans un marché public sont très limitées, principalement du fait que les administrations françaises ont obligation d'utiliser le français pour leurs documents contractuels alors que très peu de licences libres sont disponibles en français. Par exemple, la licence GPL (General Public Licence) la plus utilisée ne dispose pas de traduction “reconnue” en français. Par ailleurs, l'administration doit privilégier les licences de type héréditaire (Copyleft) garantissant que l'investissement public continuera de profiter à tous. Au final, les licences répondant à ces contraintes sont les licences :
1. CeCILLv21 (à l'initiative du CEA, du CNRS et de l'INRIA), rédigée en référence au droit français, compatible selon sa clause de comptabilité avec la licence GNU GPL et EUPL. La licence est reconnue depuis juillet 2013 par l'Open Source Initiative2;
2. EUPLv1.13 (European Union Public Licence à l'initiative de la Commission européenne) rédigée en référence au droit européen et reconnu par l'Open Source Initiative4, compatible selon sa clause de compatibilité avec les licences GNU GPLv.2, OSL v. 2.1 et v. 3.0, Common Public License v.1.0, Eclipse Public License v. 1.0 et Cecill v. 2.0.
Bah, Arduino c'est sans mystère ou presque, simple, efficace, etc. Après, le coût de R&D pour faire des capteurs avec est à voir (cartes spécifiques, conception de boîtier et impression 3D, etc).
Pour les CPUs NVIDIA, je me méfie un peu car j'ai eu quelques déconvenues avec du tegra 3 à l'époque, mais ça a certainement changé depuis. Je regarderai. Merci pour le lien en tout cas !
Merci pour ton encouragement. Je donnerai des news assurément. Le projet me motive beaucoup.
Le mini-PC ldlc est un exemple. J'ai vu passer ce type de produit à environ 300€ avec une garantie constructeur de 5 ans quand même :-)
Pour la question du MTBF : j'ai lu vite fait des choses là dessus, ça intègre des statistiques d'ensemble des composants, etc. Mais quand un constructeur donne cette valeur, c'est en général un gage de qualité. Ex : firewall SSG5, MTBF 20 ans… Autre exemple : quand je choisi un disque dur, je veille toujours à ce que le MTBF soit donné.
Sur ce projet, je sort de ma zone de confort et d’exigence habituelle. Mais je trouve l'approche très intéressante. A moi de la rendre rationnelle et raisonnée.
Merci pour ton retour.
Je comprends bien ton point de vue. Et j'avoue que le choix de la RPI2 sur le long terme ne me plaît pas au niveau fiabilité matérielle. Tu vas hurler je pense, mais l'idée du client à la base c'est RPi + arduinos, + des automates ou autres produits d'acquisition. A moi de voir si on s'écarte de ça, c'est mon rôle de conseil.
J'ai fait un POC avec une RPI2 et un Mele PCG03. La RPI2 rame un poil (zabbix serveur). Donc je m'orienterai vers du mini pc (ex : http://www.ldlc.com/fiche/PB00197324.html) si le client veut avoir des agrégateurs avec graphes locaux. Sinon ce sera carte ARM. Auquel cas, je prendrai le temps nécessaire pour juger des autres solutions dont plusieurs lecteurs m'ont parlé dans ce thread. En tout cas merci à tous pour vos retours, j'ai découvert des produits à base d'ARM qui ont l'air bien sympa :-)
Tu as tout à fait raison sur ton analyse, et je le ferai (c'est prévu depuis que j'ai commencé à réfléchir au projet). L'idée est d'optimiser le coût total de possession sur le long terme. Je n'ai pas encore tous les éléments pour commencer cette analyse. Et je ne suis pas encore arrêté sur le choix du matériel. J'ai juste passé le stade du POC. En tout cas merci pour ton retour.
Pour rester simple et efficace sur la discussion :
robustesse / fiabilité : il y a des arguments chez le constructeur pour vérifier ça ? Un calcul de MTBF, une comparaison de design d'une partie importante, ce genre de chose afin de juger objectivement ?
maintenance sur le long terme :
1) on commence à avoir le même problème sur les PCs avec des vieux drivers de chipsets je crois (PC > 12/15 ans, un membre a eu le problème dans mon hackerspace) : les drivers ne suivent pas l'évolution de version noyau car il n'y a personne de motivé pour les mettre à jour.
2 De ce que j'ai eu comme expérience, pour les cartes indus ARM, il y a 2/3 ans de mises à jours, après le constructeur passe à autre chose. Donc la sécurité du système est compromise au bout de 2/3 ans (à moins de passer du temps à faire tout évoluer soi même), donc en bon ingé, je suis obligé de la changer. Donc la question de la diffusion / communauté est hyper importante au niveau coût total de possession à horizon 10 ans.
3) A mon sens ça ne sert à rien d'avoir un SOC avec un MTBF de 20 ans, sans support long terme pour la distro linux qu'il y a dessus. Et là c'est quand même avec le nez que tu dois juger, mais c'est le même process que de choisir une brique libre ou open-source dans un système d'information (évaluation de la communauté, de la diffusion, de la médiatisation, …).
Et j'ai vu que le thread partait en cacahuète, essayez de vous comprendre les gars. On est pas obligé d'avoir tous le même point de vue… et pour détendre l’atmosphère, je citerai les inconnus : "vous allez vous aimer les uns les autres bordel de merde ?" ;p
La on s'écarte du sujet principal. Je connais bien ton point de vue, je l'ai eu également. Mais là on cherche pas à faire un système indus. Pour plusieurs raisons (prix initial, maintenabilité facile, formation rapide disponible, …). Pour l'air salin je connais aussi (j'ai intégré des serveurs embarqué à bord de navires). Après, je n'ai pas trouvé sur Internet les cartes blue-steel. Mais j'ai regardé chez Olimex, ils ont des gammes très sympa, merci du tuyau ! Par contre, est ce que le système sera maintenu sur le long terme ? C'est à dire Debian mis à jour ? C'est toujours le problème avec les cartes ARM : le suivi des produits par le constructeur sur le long terme. Avec les Rpi, j'ai pas de problème vu la diffusion et l'adoption très large. Avec les Olimex, je me pose la question ? Eh oui, il faut penser à la sécurité sur le long terme. Ce ne sont pas des systèmes isolés que je vais mettre en place. Mais bon, au final j'aurai certainement besoin de mini-pcs :-)
[^] # Re: Directive EnvironmentFile pour l’unité systemd
Posté par ghusson (site web personnel) . En réponse au journal Zabbix, autossh, systemd. Évalué à 1.
A moins que je n'ai pas compris ton idée, pour moi ce n'est pas nécessaire.
Il y a 1 seul autossh par OS client.
Après pour l'environment file, pourquoi pas. Normalement la bonne pratique serait un fichier /etc/default/autossh_zabbix par exemple. Mais pour ce cas j'ai voulu quelque chose de simple et d'autoporteur. A améliorer avant déploiement massif.
Pour le %i j'ai rencontré ça avec getty. Tiens je vais faire un journal :-) J'ai un peu galérer pour la sonsole sur port série ;p
[^] # Re: HEREDOC et variables
Posté par ghusson (site web personnel) . En réponse au journal Zabbix, autossh, systemd. Évalué à 1.
Je ne comprends pas bien le sens de ta question.
J'utilise cette méthodo : variables, template, sed parce que pour le moment je ne me suis pas mis à des moteurs de templating ou d'industrialisation de déploiement / gestion de conf. Donc pour moi c'est le bon moyen de séparer les choses en attendant mieux (Ansible / Salt). Avec cette méthode (cat/sed) je ne suis pas embêté avec les problèmes de caractères d'escaping dans les variables bash.
[^] # Re: Merci
Posté par ghusson (site web personnel) . En réponse au journal Zabbix, autossh, systemd. Évalué à 2.
Je comprends tout à fait ton point de vue. Et je n'ai pas finalisé le tout. Saches que :
1) c'est un hack pour chiffrer le protocole de zabbix, bien que la gateway de reverse SSH soit intéressante fonctionnellement
2) les services tournent sur les OS clients (donc 1 seul service par OS, pas 100 sur un)
3) pour faire propre, il faudrait soit un système de déploiement automatique type Ansible, soit faire un paquet, soit packager un minimum et en effet sortir la conf
4) il doit y avoir une corrélation entre l'ID zabbix, l'ID du tunnel et donc les ports
Bref, c'est loin d'être fini pour une mise en production massive et parfait. Mais en attendant ça fait bien le job.
Après en documentant, ce système reste simple et efficace donc pas cher à mettre en œuvre, si il y a peu de noeuds distants. Tu connais la loi des 80/20 ? Il faut rester rentable. Et je pense qu'avec un petit coup d'Ansible ça va le faire :-)
Après sur la question de la doc, c'est toujours pareil, l'admin qui ne documente pas suffisamment afin qu'il (ou la société qui l'emploie) puisse être tranquille si du jour au lendemain il n'est plus dans la boite (vacances, maladies, quoi que ce soit), est un mauvais admin. Ou alors il n'a pas su convaincre sa hiérarchie de l'intérêt de documenter.
Au sujet de ta notion de wrapper, pourquoi pas. Mais il est lancé par quoi ? rc.local ? Je ne suis pas d'accord. Systemd a été choisi par Debian. Il a son rôle. Il faut l'utiliser (lancer, maintenir, renvoyer l'état, gérer les services/démons). Ok, il faut faire l'effort de lire la doc. Mais tu utilises toujours ifconfig ou tu es passé à ip link/addr/route ? :-)
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par ghusson (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 1.
OK. Et pour info pourquoi avec choisi POM plutôt que Zabbix ? Simplicité de déploiement ?
[^] # Re: Merci
Posté par ghusson (site web personnel) . En réponse au journal Zabbix, autossh, systemd. Évalué à 2.
C'est pas compliqué quand on lit la doc de systemd (j'ai pris 3h pour ça en passant, c'était l'occasion de m'y mettre :-).
[^] # Re: Merci
Posté par ghusson (site web personnel) . En réponse au journal Zabbix, autossh, systemd. Évalué à 1. Dernière modification le 10 avril 2016 à 22:16.
Personnellement je considère autossh comme le démon. Le bash autour n'est la que pour gérer le lancement du démon et les variables. Et systemd gère le service.
Après pour le déploiement, la configuration, ce serait en effet plus judicieux d'utiliser un système comme Ansible par exemple. Mais ça ne change pas la base de la solution :-)
[^] # Re: Merci
Posté par ghusson (site web personnel) . En réponse au journal Zabbix, autossh, systemd. Évalué à 2.
Qu'est ce que tu reproches au fait que j'utilise systemd pour gérer un service ? Moi ça me paraît naturel.
En relisant, j'ai laissé traîner des droits abusifs pour le fichier, qui devraient être en 644 au lieu de 755 (si un gentil modérateur passe par la…). Après, je ne sais pas si je fais tout bien avec systemd (wantedby) mais le fait est que ça fonctionne.
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par ghusson (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 1.
J'avais déjà vu passer POM. Mais c'est pas libre d'après ce que j'ai vu rapidement sur leur site ?
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par ghusson (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 2.
Bon ben quitte à être dans les cadeaux, je vous met à dispo mes scripts autossh pour zabbix :-)
https://linuxfr.org/users/ghusson/journaux/zabbix-autossh-systemd
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par ghusson (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 3.
Personnellement j'utilise zabbix depuis 2009. J'ai développé des scipts d’auto-découverte pour linux qui me permettent de déployer très vite la supervision des nouveaux serveurs (voir ici : https://share.zabbix.com/operating-systems/linux-autodiscovery-disks-proces-tcp-udp-service).
Zabbix a mis en place un site (béta) d'échange : https://share.zabbix.com/ ce qui est bien bien pratique.
De plus la V3 va permettre les communications chiffrées, ce qui va me permettre d'enfin utiliser les commandes à distance (ex : prendre un ps, iotop, atop de la machine en cas de dépassement de métriques).
Sur le sujet du monitoring, j'ai découvert récemment une communauté : http://www.monitoring-fr.org/
Pour un tour d'horizon des solutions, voir ici : http://wiki.monitoring-fr.org/supervision/links
Mes 2 cents.
# Ahhh je vois que je ne suis pas le seul à y avoir pensé :-)
Posté par ghusson (site web personnel) . En réponse au journal Yocto+Docker: Les containers personnalisé. Évalué à 3.
Ça me fait plaisir de voir ça. J'y avais pensé mais je n'ai pas pris le temps de tester :-)
Merci pour le partage !
Après pour optimiser l'empreinte, il est possible de ne prendre que les binaires et les librairies nécessaires (via un script d'automatisation qui cible des binaires définis). J'avais déjà fait ça pour un système de backup à chaud qui créait un ré-installeur sur USB dans un job précédent. Les scripts de bases sont présents sur le net.
# elgg
Posté par ghusson (site web personnel) . En réponse au journal Besoin de compétences numériques à la #nuitdebout. Évalué à 2.
Bonjour,
Concernant ton besoin, il y a elgg qui peut coller. solution de type réseau social d'entreprise (très simple et modulaire).
Je l'ai mis en test pour le CREPP (asso type hackerspace à Lorient). Il est en jachères depuis quelques mois avant packaging et lancement mais ça te donnera une idée. Et il y a un module de vote pour info :-)
elgg : https://elgg.org/
site de mon asso : http://fil.crepp.org
Après, je peux faire des prestation par ma boite Liberasys. Mais apparemment, de gentils administrateurs sont prêt à vous aider bénévolement, donc c'est super !
[^] # Re: Heureusement, il y avait une dépêche pour ça :)
Posté par ghusson (site web personnel) . En réponse au journal Proxmox VE : nouveautés de la version 4 et conjonction avec Nexenta. Évalué à 2.
Oui j'ai vu. J'ai voulu donner plus de détails. Et mon retour d'expérience avec Nexenta (utilisation de ZFS over iSCSI).
# j'ai un autre point de vue
Posté par ghusson (site web personnel) . En réponse au journal Vivre en fascisie. Évalué à 7.
Bonjour,
Désolé je n'ai pas lu avec attention tout ton article. A "négation de l’altérité" j'ai décroché et à "manichéisme boulimique" tu m'as définitivement perdu. Je pense que ton analyse n'est pas dénuée de sens. Malgré cela, je lis linuxfr.org depuis de nombreuses années (2009 si je me souviens bien). Et c'est une de mes sources de veille technologique pour l'open source et le logiciel libre. J'ai créé ma société en 2015 et j'ai décidé de contribuer. Résultat : exactement ce à quoi je m'attendais :-)
Des commentaires de plusieurs ordres :
- objectifs, ou subjectif et acerbes : faisant avancer la réflexion et développer notre champ de connaissance (ceux la je les préfère),
- des remerciement (ça fait toujours plaisir de voir que son travail sert à quelque chose et qu'il est apprécié),
- pourquoi avoir fait ça (c'est quoi l’intérêt) : des membres qui n'ont pas la même vision ou le même champ d’application ou qui ont eu l'information ailleurs (soit je transmet une information soit j'en reçoit une - ex : ah, oui quelqu'un l'avait déjà fait… pourquoi je me suis embêté pour rien :-),
- hors sujet : non lié au sujet, un ovni quoi (l'auteur a certainement lu de travers ou veut vite fait partager une expérience, mais ça tombe à l'eau),
- insulte : je n'ai pas encore eu :p (mais à éviter).
Après, il faut bien réaliser que les membres postent souvent vite fait sans se soucier des formes… Ce qui conduit à une montée en pression des commentaires. Mais ce n'est pas nouveau… dans les milieux de passionnés, surtout sur internet, ça arrive régulièrement (c'est pour cela qu'on a inventé les points Godwin ;-) Les mots ne représente que 7% d'un message alors imagine les incompréhensions, les quiproquos, les sentiments d'injustice, etc. C'est pour cela qu'il faut se retenir de poster des commentaires "à chaud", sans réflexion préalable et sans un minimum de forme. Mais personnellement, je préfère avoir des commentaires quels qu'ils soient plutôt qu'un grand vide :-) En effet, un commentaire c'est quelqu'un qui prends le temps d'écrire une réaction, une réflexion, une information… et ça a de la valeur.
Pour conclure, je trouve que tu juges beaucoup. Pour ma part, je pense qu'avant de juger il faut connaître et quand on connaît, on a plus envie de juger. Ici on est entre connaisseurs du monde open source et du libre. On est des passionnés. Si il n'y avait pas de discussions enflammées, de un on se ferait ch*** et de deux tu trouverais ça normal ? ;p
[^] # Re: Qu'est-ce qui freine la migration à l'IPv6 ?
Posté par ghusson (site web personnel) . En réponse au journal Des abonnés Free reçoivent ¼ d’adresse IP. Évalué à -5.
Là on aborde la problématique côté FAI et client final de type particulier. Il y a aussi les entreprises. Et pour celles ci, il y en plus les problèmes de sécurité lié à IPv6. Pour un aperçu, je vous propose ce podcast : https://www.nolimitsecu.fr/ipv6/
[^] # Re: Forum Etalab
Posté par ghusson (site web personnel) . En réponse au journal License pour un système de journalisation/supervision de consommations énergétiques (pour une Ville). Évalué à 2.
Et pour l'opendata, ils ont créé une licence : https://www.etalab.gouv.fr/licence-ouverte-open-licence
[^] # Re: Forum Etalab
Posté par ghusson (site web personnel) . En réponse au journal License pour un système de journalisation/supervision de consommations énergétiques (pour une Ville). Évalué à 2.
En fouinant sur etalab, je suis tombé sur un lien (http://www.economie.gouv.fr/apie/administrations-logiciels-libres-clausier-marches-publics) qui renvoie sur un document intéressant. Extrait :
Les licences de logiciel libre qu'il est possible de viser dans un marché public sont très limitées, principalement du fait que les administrations françaises ont obligation d'utiliser le français pour leurs documents contractuels alors que très peu de licences libres sont disponibles en français. Par exemple, la licence GPL (General Public Licence) la plus utilisée ne dispose pas de traduction “reconnue” en français. Par ailleurs, l'administration doit privilégier les licences de type héréditaire (Copyleft) garantissant que l'investissement public continuera de profiter à tous. Au final, les licences répondant à ces contraintes sont les licences :
1. CeCILLv21 (à l'initiative du CEA, du CNRS et de l'INRIA), rédigée en référence au droit français, compatible selon sa clause de comptabilité avec la licence GNU GPL et EUPL. La licence est reconnue depuis juillet 2013 par l'Open Source Initiative2;
2. EUPLv1.13 (European Union Public Licence à l'initiative de la Commission européenne) rédigée en référence au droit européen et reconnu par l'Open Source Initiative4, compatible selon sa clause de compatibilité avec les licences GNU GPLv.2, OSL v. 2.1 et v. 3.0, Common Public License v.1.0, Eclipse Public License v. 1.0 et Cecill v. 2.0.
De plus, ce document contient des propositions de rédaction de CCAG/CCAP. Si une personne du service public passe par ici, voir : http://www.economie.gouv.fr/files/files/directions_services/apie/page-adm-et-PI/textes-et-temoignages/CCAG_TIC_2014.odt
Donc au final j'ai une réponse officielle à ma question ! :-)
[^] # Re: Pour mon information
Posté par ghusson (site web personnel) . En réponse au journal License pour un système de journalisation/supervision de consommations énergétiques (pour une Ville). Évalué à 2.
Bah, Arduino c'est sans mystère ou presque, simple, efficace, etc. Après, le coût de R&D pour faire des capteurs avec est à voir (cartes spécifiques, conception de boîtier et impression 3D, etc).
Pour les CPUs NVIDIA, je me méfie un peu car j'ai eu quelques déconvenues avec du tegra 3 à l'époque, mais ça a certainement changé depuis. Je regarderai. Merci pour le lien en tout cas !
Merci pour ton encouragement. Je donnerai des news assurément. Le projet me motive beaucoup.
[^] # Re: Forum Etalab
Posté par ghusson (site web personnel) . En réponse au journal License pour un système de journalisation/supervision de consommations énergétiques (pour une Ville). Évalué à 1.
Merci pour le lien, mais vu la jeunesse du forum, je vais attendre un peu :-)
[^] # Re: Pour mon information
Posté par ghusson (site web personnel) . En réponse au journal License pour un système de journalisation/supervision de consommations énergétiques (pour une Ville). Évalué à 1.
Le mini-PC ldlc est un exemple. J'ai vu passer ce type de produit à environ 300€ avec une garantie constructeur de 5 ans quand même :-)
Pour la question du MTBF : j'ai lu vite fait des choses là dessus, ça intègre des statistiques d'ensemble des composants, etc. Mais quand un constructeur donne cette valeur, c'est en général un gage de qualité. Ex : firewall SSG5, MTBF 20 ans… Autre exemple : quand je choisi un disque dur, je veille toujours à ce que le MTBF soit donné.
Sur ce projet, je sort de ma zone de confort et d’exigence habituelle. Mais je trouve l'approche très intéressante. A moi de la rendre rationnelle et raisonnée.
[^] # Re: Pour mon information
Posté par ghusson (site web personnel) . En réponse au journal License pour un système de journalisation/supervision de consommations énergétiques (pour une Ville). Évalué à 3.
Merci pour ton retour.
Je comprends bien ton point de vue. Et j'avoue que le choix de la RPI2 sur le long terme ne me plaît pas au niveau fiabilité matérielle. Tu vas hurler je pense, mais l'idée du client à la base c'est RPi + arduinos, + des automates ou autres produits d'acquisition. A moi de voir si on s'écarte de ça, c'est mon rôle de conseil.
J'ai fait un POC avec une RPI2 et un Mele PCG03. La RPI2 rame un poil (zabbix serveur). Donc je m'orienterai vers du mini pc (ex : http://www.ldlc.com/fiche/PB00197324.html) si le client veut avoir des agrégateurs avec graphes locaux. Sinon ce sera carte ARM. Auquel cas, je prendrai le temps nécessaire pour juger des autres solutions dont plusieurs lecteurs m'ont parlé dans ce thread. En tout cas merci à tous pour vos retours, j'ai découvert des produits à base d'ARM qui ont l'air bien sympa :-)
[^] # Re: Pour mon information
Posté par ghusson (site web personnel) . En réponse au journal License pour un système de journalisation/supervision de consommations énergétiques (pour une Ville). Évalué à 1.
Tu as tout à fait raison sur ton analyse, et je le ferai (c'est prévu depuis que j'ai commencé à réfléchir au projet). L'idée est d'optimiser le coût total de possession sur le long terme. Je n'ai pas encore tous les éléments pour commencer cette analyse. Et je ne suis pas encore arrêté sur le choix du matériel. J'ai juste passé le stade du POC. En tout cas merci pour ton retour.
[^] # Re: dimensionnement du serveur ?
Posté par ghusson (site web personnel) . En réponse au journal Diffusion de fichiers sur tablettes Android. Évalué à 3.
Owncloud + cache + bonne quantité de RAM ?
[^] # Re: Pour mon information
Posté par ghusson (site web personnel) . En réponse au journal License pour un système de journalisation/supervision de consommations énergétiques (pour une Ville). Évalué à 7.
Pour rester simple et efficace sur la discussion :
robustesse / fiabilité : il y a des arguments chez le constructeur pour vérifier ça ? Un calcul de MTBF, une comparaison de design d'une partie importante, ce genre de chose afin de juger objectivement ?
maintenance sur le long terme :
1) on commence à avoir le même problème sur les PCs avec des vieux drivers de chipsets je crois (PC > 12/15 ans, un membre a eu le problème dans mon hackerspace) : les drivers ne suivent pas l'évolution de version noyau car il n'y a personne de motivé pour les mettre à jour.
2 De ce que j'ai eu comme expérience, pour les cartes indus ARM, il y a 2/3 ans de mises à jours, après le constructeur passe à autre chose. Donc la sécurité du système est compromise au bout de 2/3 ans (à moins de passer du temps à faire tout évoluer soi même), donc en bon ingé, je suis obligé de la changer. Donc la question de la diffusion / communauté est hyper importante au niveau coût total de possession à horizon 10 ans.
3) A mon sens ça ne sert à rien d'avoir un SOC avec un MTBF de 20 ans, sans support long terme pour la distro linux qu'il y a dessus. Et là c'est quand même avec le nez que tu dois juger, mais c'est le même process que de choisir une brique libre ou open-source dans un système d'information (évaluation de la communauté, de la diffusion, de la médiatisation, …).
Et j'ai vu que le thread partait en cacahuète, essayez de vous comprendre les gars. On est pas obligé d'avoir tous le même point de vue… et pour détendre l’atmosphère, je citerai les inconnus : "vous allez vous aimer les uns les autres bordel de merde ?" ;p
[^] # Re: Pour mon information
Posté par ghusson (site web personnel) . En réponse au journal License pour un système de journalisation/supervision de consommations énergétiques (pour une Ville). Évalué à 4.
La on s'écarte du sujet principal. Je connais bien ton point de vue, je l'ai eu également. Mais là on cherche pas à faire un système indus. Pour plusieurs raisons (prix initial, maintenabilité facile, formation rapide disponible, …). Pour l'air salin je connais aussi (j'ai intégré des serveurs embarqué à bord de navires). Après, je n'ai pas trouvé sur Internet les cartes blue-steel. Mais j'ai regardé chez Olimex, ils ont des gammes très sympa, merci du tuyau ! Par contre, est ce que le système sera maintenu sur le long terme ? C'est à dire Debian mis à jour ? C'est toujours le problème avec les cartes ARM : le suivi des produits par le constructeur sur le long terme. Avec les Rpi, j'ai pas de problème vu la diffusion et l'adoption très large. Avec les Olimex, je me pose la question ? Eh oui, il faut penser à la sécurité sur le long terme. Ce ne sont pas des systèmes isolés que je vais mettre en place. Mais bon, au final j'aurai certainement besoin de mini-pcs :-)