Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Il serait temps d'implémenter une procédure de soft power down.

Pour éteindre une Freebox on la débranche à l'arrache… ce qui est possible lorsque la Freebox n'a pas de disques mécaniques.

Avec un disque mécanique il y a toujours une probabilité certes faibles, qu'une extinction à l'arrache se fasse au pire des moments et engendrent une détérioration des données irréversibles.

Des utilisateurs qui renvoient leur Freebox Revolution avec disque out, IL Y EN A PLEIN, ce n'est pas une majorité certes, mais cessez de vous voilez le visage, les disques dur mécaniques qui lâchent ça existe bel et bien.

La faible capacité de la Revolution faisait que personne ne s'en servait comme un NAS, donc pas de données critiques le DD de la Révolution était juste un cache de données.

Avec la Delta TOUT CHANGE, et il faut que les développeurs ACCEPTENT D'EN PRENDRE CONSCIENCE.
Il existe des disques dur mécaniques de 2.5 pouces en 5 TO, donc théoriquement le Delta peut gérer un NAS de 20 TO

Le nombre de disques augmentant le risque de pertes de données irréversibles liées à une coupure brutale EST NETTEMENT PLUS ELEVEE
Ajoutons qu'avec 20 TO, là on parle d'utilisateurs qui gèrent des données sensibles car on ne rebatit pas une bibliothèque de 20 de données comme cela.

L'implémentation d'un soft power down pour éteindre définitivement la Freebox (ou a minima la mettre en veille et autoriser une déconnexion de la prise haute tension en toute sécurité) me parait indispensable

Dans un soft power down commandé via l'écran tactile ou via Freebox OS, l'OS va achever toutes les opérations en cours ou les terminer proprement, vider tout son cache d'écriture sur les disques dur, il va commander le parquage des têtes de disques dur dans un endroit sûr, et va enfin demander au BIOS d'éteindre la machine.

C'est ce qui se passe sur un PC de monsieur tout le monde. Toute le monde sait qu'éteindre brutalement un PC peut conduire à des choses plus ou moins catastrophiques, même si statistiquement, NTFS, Ext4 se révèlent assez robustes (pour EXT4 il faut bien ajuster ses paramètres et notamment choisir l'option de montage data=journal, l'option par défaut choisie par nombre de distributions data=ordered EST TOTALEMENT INSUFFISANTE)

La Delta étant plus compacte que la Revolution en ces jours d'été venant, elle est sensiblement plus bruyante vu que les ventilos tournent toujours à fond. Les gens peuvent être tenté d'éteindre cette machine quand ils se couchent si ça les gêne pour dormir, donc les opérations d'extinction à l'arrache pourrait se multiplier durant la période estivale et causer un nombre sensible de déconvenues en terme de pertes sèches de données.

1) Suppression du protocol SMB1

L'activation du SMBv2 rend inactif le SMBv1 contrairement à ce qui était sous entendu sur la page principale de votre site, sauf si j'ai mal compris.

J'ai personnellement encore certains zinzins qui ne se connectent qu'en SMBv1, alors que Windows 10 et Linux réclament le SMBv2 par défaut, mais bon…. je ne dois pas être un cas commun. Outre les problèmes de sécurité du SMB1, le SMB2/3 est quand même plus performant, d'où l'intérêt que j'aurais à mixer les protocoles.

En fait j'ignore si l'activation simultanée des 3 protocoles est vraiment possible, je n'ai pas encore fait de test approfondi sur mes systèmes, mais j'avais cru voir dans la doc "Samba" les paramètres min et max protocol de /etc/samba/smb.conf

Donc si on place

min protocol = SMB1
max protocol = SMB3

Théoriquement le serveur pourrait accepter l'authentifcation cumulée selon les 3 protocoles….. sous réserve de tests. Peut-être que le cumule n'est possible que sur les deux derniers protocoles…

Dans tous les cas, ça pose un souci.
Pour des raisons de sécurité certaines personnes ne veulent absolument plus que le serveur serve le protocole SMB1 (c'est juste moi qui suis dans un cas particulier et j'assume le risque qui va avec), donc placer min protocol à SMB2 semble répondre à la demande majoritaire.

Pour résoudre le problème des gens qui pour certaines raisons ont besoin des protocoles cumulés 1, 2, 3 ça implique donc que l'interface Freebox OS soit modifiée.

La Freebox par défaut active les protocoles 2/3 et on a une case à cocher SMB1, qui permet explicitement d'activer le SMB1 EN PLUS (avec un petit écran d'avertissement sur les problèmes de sécurité induits) si tant est que le cumul des 3 protocoles est vraiment possible.

Bien entendu, lors de la mise à jour, pour ne pas disturber les utilisateurs la case SMB1 est automatiquement cochée si un serveur est déjà paramétré selon ce protocole, mais pour les nouveaux clients, la box doit décocher par défaut le SMB1 et activer par défaut SMB2 / SMB3

2) Modification des noms de partage

Lorsque l'on active le SMBv2, il semblerait que le serveur Samba de Freebox OS modifie les noms de partage contenant des majuscules en passant tout en minuscule. Si ce n'est pas en soit critique, c'est ennuyeux car ça implique de modifier tous les informations d'identification au niveau des clients.

Dans les standards Windows, contrairement à Linux, les minuscules et majuscules sont discriminantes par défaut. En revanche je ne sais pas ce qu'il advient des caractères accentués… en effet, dans l'univers Windows l'utilisation de noms de partages contenant des caractères accentués est monnaie courante, contrairement au monde Linux.

Il faut donc s'attendre à ce qu'un nombre important de réclamations alléguant l'impossibilté de se connecter viennent d'un changement de casse.

Normalement c'est un simple paramètres dans Samba qui indique si minuscules et majuscules sont discriminantes.
Du reste, il suffit de revenir en SMB1 et comme par magie tout revient en ordre.

NB : Pour rappel la fameuse faille de sécurité ne conduit pas directement à un black out du PC. Le virus par définition doit être activée sur un poste client via par exemple une pièce jointes d'un email, et le virus s'il détecte la présence de serveurs Samba SMB1 va exploter la faille pour se diffuser à travers tout le réseau. Le risque est donc essentiellement pour les entreprises qui peuvent voir tous les postes de l'entreprise progressivement infectés

Ma demande est totalement lunaire, je le conçois mais....

ZFS pourrait très bien être le système d’exploitation presque universel de demain.

- ZFS marche très bien sur FreeBSD (et Solaris bien entendu qui est son OS d’origine)

- ZFS a été implémenté sur Linux via OpenZFS, sa prise en charge est désormais très très avancée sur certaines distros, prise en charge à un état de maturité bien supérieure à BTRFS qui reste ultra expérimental, au point que Ubuntu a décidé de l’implémenter par défaut en lieu et place de BTRFS

OpenZFS est disponible en beta version sur canaux alternatifs sur openSUSE Tumbleweed tant sur plateforme x86 qu’ARM

- Mais surtout surtout.... OpenZFS a été porté sur Windows.

https://openzfs.org/wiki/Main_Page https://github.com/openzfsonwindows/ZFSin

Le portage sous Windows n’est pas un vulgaire portage via Dokan (l’équivalent Windows de FUSE) comme ça a pu être le cas sur des projets précédents, il s’agit d’un driver NATIF dont l’état de développement est très avancé. Ce driver promet donc une prise en charge à quasi identité avec les projets OpenZFS sur Linux, ou ZFS sur FreeBSD, c’est un projet opensource et GRATUIT

J’ai installé ZFS sur mes PCs, j’ai déjà expérimenté des échanges entre Linux, Windows... c’est juste bluffant, même si tout n’est pas encore parfait.

Windows a perdu son driver ext2/ext4 car extfsd n’est plus développé, le support s’arrête à Windows 7
La seule solution en lecture écriture reste une solution payante Paragon basée sur Dokan, donc ce n’est qu’un vulgaire systeème FUSE avec toutes ses limitations. De plus Dokan étant utilisé par d’autres logiciels comme Cryptomator, Seadrive, on se retrouve parfois avec des conflits inextricables de driver Dokan, des BSOD donc exit Paragon, on se contentera de lire les volumes Ext2/3/4 en lecture seule gràace à LinuxRead

Un disque USB en ZFS, la grappe raid de la Freebox qui serait alors en ZFS et non plus en mdm, pourraient être indifféremment réimportés vers des systèmes FreeBSD, Linux, Windows avec une performance NATIVE

Autre avantage ZFS implémente par défaut le système de droits NFSv4 complètement compatible avec le système de droit NTFS de Windows, ce qui faciliterait encore plus la transportabilité des données, permettrait de gérer avec plus de finesse les droits sur le serveur Samba de la box

Samba dans ses dernières impplémentations offrent l’option de système de fchier ZFS pour tirer partie de sa gestion native de NFSv4

ZFS ne remplacera pas NTFS, EXT4, FAT32... pour de multiples raisons assez complexes comme le fait que ZFS est aussi par nature un gestionnaire de volume qui peut donc entrer en conflit avec certains matériels comme les faux raid matériel.

ZFS est au départ conçu pour des énormes serveurs de données, et la gestion en direct de grappes RAID... mais de façon inattendue suite au projet OpenZFS on Windows, ZFS peut donc devenir l’alternative universelle de demain même pour l’usager lambda. Il faudra juste sous Windows que des gens développent des interfaces graphiques pour la configuration et la maintenance de ZFS