Le 06/09/2021 à 13h 28

Peut être qu’ils n’utilisent pas pgp var ils ont tous basculés sur age ;) ( https://github.com/FiloSottile/age) (je plaisante mais qu’à moitié : age est sans doute en passe de supplanter pgp en terme d’efficience de solution, mais quant à sa mise en place au sein d’autres systèmes et quant à une éventuelle large adoption, c’est sur que ce n’est pas gagné…)

Le 24/01/2021 à 17h 05

xillibit a dit:

QNAP a aussi un modèle avec 8 ports 2,5Gb/s et des ports SFP+ : https://www.qnap.com/fr-fr/product/qsw-m2108-2c

Oui … mais + de 300€ (notamment car 2 ports 10Gb/s).

Le 20/01/2021 à 23h 23

Il serait plus que temps que des switch 2.5Gbps 8 x ports soient massivement disponibles, il y a encore très peu de modèles … à priori c’est le premier 8 ports 2.5G que je vois passer.

Evidemment ce TP-LINK va : être disponible dans bien trop longtemps à la commercialisation, et sans doute malheureusement à un prix prohibitif (vu le tarif de la (rare) concurrence).

Le 17/12/2020 à 11h 49

Difficile, le service gratuit est devenu quasi inutilisable. J’ai voulu retester ce samedi, j’ai lancé une fenêtre a 14h00, ça m’annonçait initialement 52 minutes d’attente … résultat, le soir a 21h00, j’étais toujours en file d’attente …

Peut-être victime de son succès, ce service.

Le 17/05/2020 à 20h 24

IFTTT - en tant que moteur de règles permettant d’automatiser des actions en fonctions d’événements - a toujours été une totale aberration pour un usage lié à son réseau domestique (donc pour des règles domotiques, liées à des devices que l’on a chez soi, tels un routeur, des lampes HUE, etc.) - car hébergé à 100% dans le cloud et par un acteur privé.

Malheureusement il n'y a pas pléthores d'alternatives, on peut citer (à héberger chez soi bien sûr) :       

- Huginn : https://github.com/huginn/huginn  

- N8N : https://github.com/n8n-io/n8n  

- Apache Nifi : https://nifi.apache.org/index.html  

- Eventuellement node-red, mais c'est plus ouvert (potentiellement plus puissant mais aussi plus ardu)      

- D'autres projets open-source existent, mais souvent moins aboutis / avancés.      

       

Huginn est un peu, un peu rébarbatif, mais assez puissant / stable.      

       

Bien sûr, çà dépend des "règles" à reproduire et donc des "connecteurs" disponibles - il est évident que certains connecteurs proposés aujourd'hui par IFTTTT (il y en avait tout de même bcp à ce jour) ne sont pas (actuellement ... et parfois sans doute pas avant longtemps ni même jamais) disponibles sur ces projets open-source - notamment tous les connecteurs liés à des marques (Withing, Netatmo, ...). La faute notamment aux fabricants, qui n'exposent souvent par leurs protocoles et n'ont cure des accostages avec des solutions open-source.      

Egalement, beaucoup risquent d'être déçus par ces solutions, car :       

- il faut bien sûr avoir un serveur à disposition en local tournant H24 (mais un raspberry pi ou un NAS peuvent parfois faire l'affaire, et çà permet aussi d'héberger d'autres choses)      

- ces solutions sont souvent moins "ergonomiques" qu'IFTTT (configuration parfois plus laborieuse, etc.)      

- elles requièrent clairement un coût de maintenance (installation initiale, configuration, manipulations parfois à appliquer lors des upgrades, déploiement des patchs de sécurité, ...) - toutes choses qui étaient transparentes et gratuites avec IFTTTT      

Celà dit, c'est le prix à payer pour :       

- être autonome sur son réseau et ses données       

-   ne pas dépendre d'un acteur qui peut disparaître du jour au lendemain,       

ou, comme ici, qui peut décider soudainement de changer son modèle       

commercial      

       

Après il y a bien sûr des alternatives en ligne à IFTTTT pour ceux qui voudraient migrer (= pas à héberger en local), mais souvent déjà payantes (Zapier https://zapier.com/home, Automate.io https://automate.io/, ...).

Le 22/01/2020 à 22h 26

Non, il a très clairement été annoncé / expliqué par SONOS que les boîtiers “legacy” n’auront plus de mise à jour, donc, et que celà va entraîner au fil du temps et au fur et à mesure l’arrêt des services annexes.

Dit autrement : le streaming de MP3 en local devrait encore fonctionner pendant longtemps. Mais les web  radio ou de manière plus importante, tous les services en ligne (Tidal, Qobuz, Spotify, …) ne vont plus pouvoir être diffusé sur ces anciens devices (ni sur les nouveaux s’il y a des vieux sur le même réseau, d’ailleurs, car les MAJ seront aussi bloquées sur les nouveaux dans ce cas là) dès la toute première modification technique (de quelque nature que ce soit) de l’un de ces services.

Pour illustrer : il y a quelques semaines, Spotify était indisponible tout un week-end sous SONOS, tant depuis l’appli Spotify que l’appli SONOS (alors que tout marchait très bien en direct Spotify ou sur mon ampli A/V qui est aussi compatible Spotify Connect). Ils ont dû le lundi pousser en urgence un patch controlleur+firmware pour rétablir la situation. Les détails techniques n’ont évidemment pas été publiés, mais çà aurait pu faire penser (pour donner un exemple) à un certificat expiré qu’il fallait remplacer.

A la première survenue d’un problème de ce genre, les vieux boitiers SONOS seront donc totalement inutilisables pour quiconque utilise ces services connectés (perso, c’est mon cas, et je suis donc bien embêté). Extrait du mail SONOS : “You can continue using legacy products after May, but your system will
no longer receive software updates and new features. Over time this is likely to disrupt access to services and overall functionality.”. Clairement, le “likely” n’est pas du tout du conditionnel : çà arrivera, ils ne savent juste pas quand (tel ou tel service fera une modification quelconque).

Le 08/01/2020 à 22h 40

J’aurais envie de défendre SONOS, car c’est un peu le combat du pot de terre contre le pot de fer … mais en même temps (pour être équipé de box SONOS depuis des années), ils ont fait tellement de mauvais choix à tous points de vue et ont laissé leur écosystème dans un tel mauvais état aujourd’hui (*), qu’ils ne peuvent aussi s’en prendre qu’à eux mêmes que les consommateurs se dirigent maintenant vers leurs concurrents (qui malheureusement pour eux ont de plus une force de frappe d’une toute autre ampleur).

(* zéro innovations sur les produits, nombreux retraits de fonctionnalités, zéro améliorations utiles d’aucune sorte depuis des années, bugs de plus en plus nombreux, devices rendus purement et simplement inopérants comme les controlleurs, de plus en plus de problèmes de fiabilités techniques en diffusions spotify, etc.)

Le 03/01/2020 à 16h 23

NewRoberto a dit:

Ah d’accord tu pars sur du RAID 5. j’ai toujours lu que du RAID 5 avec de telles capacités de disque, ça devait très dangereux compte tenu des temps de reconstruction

C’est vrai, il ne faut pas être pressé, même sur l’ajout d’un disque …

Sur le HELIOS4, avec des disques de 5 TO, je n’avais malheureusement pas noté le temps d’ajout d’un disque, j’avais juste copié/collé çà :

Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [raid10]

md0 : active raid5 sda1[3] sdb1[0] sdc1[2]

      4883638272 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

      [==========>..........]  reshape = 50.1% (2446718304/4883638272) finish=342.6min speed=118531K/sec

      bitmap: 0/37 pages [0KB], 65536KB chunk



unused devices: <none>

(avec 120mo / sec, une fois arrivé à 50%, il restait ~6 heures pour finir le taf (sachant que ce n’est pas tout à fait linéaire sur tout le process))

Donc en pratique plus de 12h en cas de reconstruction sur un disque HS de 5TO (l’ajout d’un disque pour agrandissement ou pour remplacement est la même manip / prend le même temps).

Et pour info pendant que j’y suis, le retaillage de la baie de 3 5TO vers 4 5TO, toujours sur l’HELIOS4 =

time resize2fs -p /dev/md0

= 33 minutes

Le 03/01/2020 à 16h 17

Aloyse57 a dit:

Il y a un truc qui me semble rédhibitoire d’entrée : l’eMMC que j’imagine soudée. Sur les 15 machines que j’ai achetées il y a 18 mois pour un usage spécifique (Atom z8350, Windows 10, utilisé comme pointeuse+badgeuse, 24h/7), 6 sont hors d’usage à cause d’une défaillance de l’eMMC. Au prix d’un SSD aujourd’hui (et un port M.2 est en plus super compact), je ne comprends pas qu’on en fasse l’impasse au profit d’un truc irréparable.

Pas faux … je n’ai jamais eu le problème (et j’ai qqs devices avec eMMC soudée, comme la carte Latte Panda), mais sur le principe, tu as tout à fait raison. Mais je pense qu’une partie de leur équation est de proposer quelque chose de complet au coût aussi maîtrisé que possible.

En complément sur ce sujet de la mémoire embarquée soudée, les créateurs de la carte HELIOS64 semblent dire :

Also we are using only quality components, not refurbished / rebranded SDRAM or eMMC modules from brand like Rayson or Foresee. For people who don’t know those refurbished chips are chips that didn’t pass quality tests from original foundries (e.g Samsung or Micron) and are resold via other channels under different brands. 

(source : CNX software)

Le 03/01/2020 à 16h 13

NewRoberto a dit:

Super, merci pour ton retour ! Tu entends quoi par “en progressif” ?

Juste le fait de commencer sur le NAS par 3 disques en RAID 5 (= 2 x la capacité utile des disques), et de rajouter un 4e disque plus tard puis un 5e encore après.

• RAID5 1 x 12 TO = impossible


• RAID5 2 x 12 TO = 12 TO utile


• RAID5 3 x 12 TO = 24 TO utile


• RAID5 4 x 12 TO = 36 TO utile


• RAID5 5 x 12 TO = 48 TO utile

En filesystem distribué (GlusterFS, etc.), c’est un peu pareil aussi, çà peut aussi se faire en progressif en rajoutant des “stack” (1 HDD + 1 carte + alim (partagée ou non)) au fur et à mesure, mais ici sans être bridé par le nombre max de slots au sein du boitier et/ou au niveau de la carte mère (en terme de nombres de slots SATA).

(bien sûr dans le cas d’un NAS “home made” avec un vrai boitier PC ou serveur, il est possible d’ajouter une carte PCI comme la LSI-9211 pour avoir des ports SATA supplémentaires pour étendre le nombre de ports SATA disponibles sur la carte, mais a) il faut que le boitier le permette en terme de place et b) c’est moins fault-tolerant que du distribué)

Le 03/01/2020 à 15h 39

Je peux faire un rapide retour sur l’HELIOS4 (que j’ai acheté).

Bien qu’ils soient au final différents :

• l’HELIOS4 était très “DIY” niveau chassis (à assembler soi même … même si c’était très simple, çà fait un peu cheap - pas gênant dans mon cas, planqué dans un rack, celà dit) alors que l’HELIOS64 serait beaucoup plus prêt “out of the box” niveau chassis”


• les performances ne seront évidemment pas les mêmes

Actuellement j’ai :

• un serveur core i3 avec 5*3 TO en RAID5, mais qui devient trop juste / trop gros


• un HELIOS4 avec 4*5 TO … dont je suis très content

Concernant l’HELIOS4, l’OS est en effet un DEBIAN (ARMBIAN) et le RAID est uniquement un raid logiciel (MDADM). Je suppose qu’il en sera de même pour l’HELIOS64 et c’est tant mieux : c’est la garantie qu’en cas de panne hardware, les disques seront remontables sans problèmes ailleurs et reconfigurables facilement avec MDADM pour récupérer les données (raison pour laquelle le RAID logiciel est souvent préférable, à mon avis, à une carte RAID hardware).

L’installation de l’OS était super simple (par JTAG via micro-USB, en lançant un terminal type “putty” sur un PC classique).
L’OS dans mon cas est sur un clé USB, les disques ne sont utilisés que pour la données en RAID.

Le kit est rangé dans un rack fermé et ne chauffe pas / est totalement silencieux (en tendant l’oreille, j’entends juste un peu les disques gratter).
Les ventilateurs tournent très faiblement et donc sans s’entendre (sauf au reboot où là ils sont pendant 30 secs de démarrage à fond).

16:30 root@helios4 ~# sensors

lm75-i2c-0-4c

Adapter: mv64xxx_i2c adapter

temp1:        +34.7°C  (high = +80.0°C, hyst = +75.0°C)

16:31 root@helios4 ~# mdadm --misc --detail /dev/md0

/dev/md0:

        Version : 1.2

  Creation Time : Fri Apr  5 22:50:14 2019

     Raid Level : raid5

     Array Size : 14650914816 (13972.20 GiB 15002.54 GB)

  Used Dev Size : 4883638272 (4657.40 GiB 5000.85 GB)

   Raid Devices : 4

  Total Devices : 4

    Persistence : Superblock is persistent

Les performances sont tout à fait correctes en lecture/écriture (et me suffisent), je suis sans pbs à 70-80mo/sec en écriture depuis le réseau (sur un simple réseau 1GBITS).

En pratique je monte en SSHFS sur mon autre NAS les fichiers exposés sur l’HELIOS (et/ou j’y accède via SAMBA depuis windows).

Bref j’en suis tout à fait satisfait. A noter que je n’y fais rien tourner (ayant un serveur à côté) d’autrese que quelques containers docker (type netdata pour le monitoring).

Je me tâte pour la suite (j’aimerais remplacer mon gros serveur-qui-prend-de-la-place-et-fait-du-bruit-et-n’est-plus-du-tout-extensible) :

• soit par quelque chose comme l’HELIOS64 (avec par ex. 5 HDD 8 voire 12 TO, en progressif) - coût raisonnable, bonne impression du premier kit, mais par contre pas du tout scalable derrière


• soit par quelque chose de distribué, qui a plein d’avantages (c’est beaucoup plus scalable au fil du temps, c’est beaucoup plus “fault tolerant”, mais pas sans danger niveau fiabilité en cas de crashs - tous ces FS sont-ils vraiment toujours stable ? Plus il faut expérimenter un minimum avant … et déjà au départ être sûr de quel FS prendre parmi la multitude qui existe déjà - GlusterFS ? LizardFS ? MooseFS ? CephFS ? et çà fait plein de câbles partout au final)