Ça fait longtemps que je n'ai plus visité facebook mais de ce que j'en sais ils veulent le faire façon AOL/portail unique de l'utilisateur donc autant ils veulent bien qu'on partage des liens vers facebook autant synchroniser le contenu lui-même ailleurs c'est pas le genre de truc qui les intéresse. J'ai bien peur que tu ne sois bloqué entre changer les habitudes de I, J et K ou créer un compte FB pour Mamie.
Je suis étonné que I, J et K utilisent encore ce dinosaure, je croyais que tout le monde utilisais snapshat ou whatsapp pour se partager des photos maintenant.
Note que si tu t'autohéberges et que tu veux une sécurité plus forte que des urls secrètes sans que Mamie n'ait à se rappeler d'un mot de passe tu peux mettre en place une authentification à base de certificats. Faudra juste trouver moyen d'installer des certificats signés chez M, I, J et K mais les navigateurs modernes permettent maintenant une installation facile en quelques clicks. Tu choisiras une date d'expiration de certificat en fonction de la durée de vie estimée de Mamie et du nombre de fois que tu as envie de répéter la manoeuvre.
I, J et K utilisent un service nuageux, autohébergé ou non depuis lequel il peuvent partager un lien unique à la fois sur FB et sur l'email de grand maman permettant à tout un chacun d'atterir sur ladite page remplie de photo. Alors certe les photos seront potentiellement visible par n'importe qui visitant le grand nain ternet mais si l'url est générée et suffisemment longue normalement on ne peut tomber dessus sans avoir le lien au préalable (et dans le cas contraire il est toujours possible de créer un compte à mamie dans ledit nuage en question)
Ça peut être du piwigo/photoshow, mais aussi du owncloud, nextcloud, cozycloud, dropbox, google photos, imgur, flickr, et j'en passe…
J'veux dire, facebook c'est à peu près le pire media pour partager facilement des photos avec de multiples interlocuteurs et l'ui est dégueulasse.
T'as jamais vu les petits bouton twitter/facebook/g+/etc sur les sites qui permettent de "partager ce contenu" ? Ben ce bouton pointe sur le domaine twitter et leur permet de savoir de quel url ils sont appelés et donc quel site/contenu tu as visité.
Raison pour laquelle la bonne pratique pour éviter d'être tracker est d'utiliser une extension qui empêche de charger du contenu externe à celui que l'on visite ou de ne consulter qu'un site à la fois et de s'y déconnecter immédiatement après.
Au niveau du déploiement/configuration de machines nous utilisons avec succès pour nos serveurs le couple The Foreman / Puppet. C'est la version "libre" de Redhat Satellite. Bien que ce soit conçu dans une optique serveur je ne vois pas ce qui pourrait bloquer un cas desktop.
Gestion des mises à jours
Pour les mises à jours il y'a plusieurs méthodes, il faudrait mieux connaître tes utilisateurs, leurs cas d'usage et types d'horaire de travail. Quelques méthodes:
La méthode bête et méchante :
Tu forces les maj tous les x temps avec un reboot imposé (par exemple tous les week-ends). Le corollaire c'est que :
Tes utilisateurs doivent être informés que s'ils laissent leur pc allumé tout document ouvert et pas sauvé sera perdu
Forcer le démarrage des machines via wakeonlan
Si des gens prennent leur laptop à la maison tu seras obligé de géré ce cas différemment
L'avantage c'est que ça nécessite peu d'outillage. Juste de pouvoir faire éventuellement du wake-on-lan et le reste c'est de la crontab.
La méthode souple:
Tu éduques tes utilisateurs pour qu'ils lancent les maj depuis l'application dédiée sur leur desktop (celle qui annonce les maj) de temps en temps et tu forces les maj de temps en temps pour le reste du backlog (en gros les utilisateurs qui ne le feraient pas. Là il faut bien connaître ses utilisteurs et savoir s'ils sont prêt.
De toute façon c'est plus où moins la même merde sous windows.
Il existe un outil console nommé apt-dater qui permet de faciliter le check et les mises à jour de groupes de machines. Bien que son nom contient "apt" il sait maintenant gérer les distribs basées sur du redhat/suse. Dans le cas où tu utiliserais un outil comme Foreman, le plugin Katello permet aussi de gérer tout cela de façon un peu plus "enterprise friendly" (en gros c'est dans l'interface web), il peut te créer des rapports sur l'état des clients et pousser des jobs de mises à jour grouper.
Le nerf de la guerre
Vu que tu parles de ne migrer qu'1/3 du parc tu vas j'imagine garder ton AD. Ce n'est pas un problème en soit car on peut utiliser l'AD pour s'authentifier sur des machines linux. Par contre tu vas devoir gérer la cohabitation parc windows/parc linux correctement. Quid de la compatibilité des formats de fichiers ? Quid de la gestion des accès sur les partages réseaux ? Quand l'utilisateur X qui est encore sous windows envoie un lien vers un fichier de type K:\nomdesondepartement\biduletruc.doc par email à ton utilisateur Y comment celui-ci saura que K:\ correspond normalement au share Bidule sur le serveur Trucmuche ? Bref fonctionnez-vous avec des share réseaux ou utilisez-vous une GED ? Quid de la messagerie ? De mon côté je m'accomode du fonctionnement de Gnome Evolution (j'avais utilisé davmail avec kmail auparavant) pour l'accès à ma boite exchange mais il me crashe quand même régulièrement des messages comme quoi il perd la connection avec l'addressbook. Si moi je peux m'en accomoder je n'accèpterai pas ce genre de bricolage avec mes utilisateurs.
Au niveau technique il y'a plein de solutions abouties pour gérer des linux en masse. Le principal challenge c'est de faire cohabiter deux mondes.
Voila, puis après il y a le coté plus ou moins complet, avec fluxbox je devrais sélectionner paquets après paquets pour mes besoin, au pif une application calculette, avec haiku j'ai déjà tout ça et tout prêt. Et puis changer un peu ça fait du bien :)
Non mais j'essaye pas de te convaincre d'utiliser du linux à la place d'Haïku, je dis juste qu'il y'a moyen de faire tourner du plus léger que la distro de base avec gros environnement de bureau.
Perso sur les vieilles machines j'aime bien mettre du openbsd. C'est hyper vite installé, à peu près tous les applis que je veux sont dispos, c'est facile à maintenir et à comprendre et ça supporte à peu près n'importe quoi à partir du intel 486.
Ça nous change de nos linux qui plus ça va plus il devient lourd, je parle surtout des deux mastodontes kde et gnome.
En même temps tu prends ton linux de tous les jours et tu démarre une session flux/openbox au lieu de kde ou gnome et c'est déjà le jour et la nuit en terme de ressenti.
Après ça va plus dépendre des applications que tu fais tourner au dessus mais j'imagine qu'on auras beau avoir un OS léger avec Haïku le jour où on porte une application comme libreoffice ou un navigateur bien moderne tu verras que la différence n'est pas aussi grand qu'elle n'y parait.
c'est surtout pour aller lire des sites,[…] pas grand chose en faite;)
Ce n'était pas le cas à l'époque où ce pc a été créé mais à notre époque javascript&co oblige c'est devenu une des activitées demandant le plus de ressources.
Si tu as une autre machine à côté sur laquelle tu peux mettre un serveur SPICE, j'en ferais plutôt un thin client à base de mini distro style tinycore linux ou puppy linux.
Si tu checks sur le store tu verras que l'écran est disponible en finition matte ou brillante. Aucune idée de la qualité mais il y'a quelques articles à leur propos sur le net.
Pour répondre également à eingrossfilou la version actuelle de kde fournie avec kde neon est la 5.10. Par contre en dessous c'est une ubuntu LTS donc déjà la vieillissante 16.04. Si tu veux des packages autres que kde bleeding edge il faudra donc passer par des backports, ppa, snaps, dépôts externes ou autre.
soit sur des bugs corrigés depuis belle lurette (KDE ou souvent Qt) mais pas distribués par avant perpette…
Il a mentionné avoir testé sous KDE neon, c'est la distrib qui reçoit justement les corrections de bugs kde les plus vite normalement. Ce sont plutôt les nouveaux bugs qu'on recevrait en premier ! Mais comme je l'ai dit dans mon post plus haut il y'a un fossé entre la kde neon user edition, qui m'a apparu très stable et la version git-stable (je n'ose même pas imaginer la git-unstable).
J'ai deux laptops sous kde neon, une en version "user edition" avec la dernière release officielle de kde5, l'autre installée avec la "developer edition git-stable". La première fonctionne très bien mais la seconde est à peine utilisable. En gros un apt upgrade sur deux tu te retrouves dans une version tellement instable de plasmashell que si tu veux bosser t'as intérêt à le killer parce qu'il te bouffe tout ton cpu. Ça perd vite de son intérêt.
Du coup je vais virer ce kde neon developer-edition, ça n'a effectivement d'intérêt que pour le dev kde qui veut débugger.
En même temps l'intérêt de la blague sur les spoilers du Sixième Sens c'est justement que dès les 5 premières minutes tout le monde en connaissait la fin.
J'ai parcouru tes liens et si je ne me trompe pas, seul le 3e lien (zfsbackup) n'exige pas que la machine où on envoie les backups soit aussi avec un filesystem ZFS. Les autres utilisent "ZFS send" et nécessite que le FS qui reçoit soit aussi en ZFS.
Oui parce que c'est plus commode et que cela permet en même temps de valider l'intégrité des données. Mais ce n'est pas obligatoire en tant que tel si le seul but est de pouvoir faire du disaster recovery par exemple.
j'avoue que je suis très très dubitatif sur le fait d'envoyer les snapshots sur une machine qui n'est pas elle-aussi en ZFS.
Faut voir ça comme une méthode d'externalisation des données à moindre coût, un peu comme quand on dupliquait des bandes magnétiques et qu'on les envoyait sur un autre site, un coffre fort de banque ou autre. C'est aussi valable pour de l'archivage. Quand t'envoies tes données sur Amazon Glacier par exemple, tu ne t'attends pas à pouvoir les restaurer à la minute non plus.
J'ai utilisé ce genre de méthode sur des machines solaris (mais sans la partie chiffrement) dans divers cas :
-dumps de bases de données
-sauvegarde de données alfresco
Faut savoir que des grosses instances alfresco, ça peut vite représenter des millions de fichiers avec beaucoup qui font moins de 1k. Avec un accès au fichier "standard" un backup est beaucoup trop long (faut oublier de faire un ls aussi). Du coup les sauvegardes à base de snapshot et d'envoi de snapshot sont très pertinentes dans ce cas. Le corrolaire c'est que tu ne peux pas restaurer un fichier individuellement mais c'est de toute façon pas un cas qui s'applique étant donné que la gestion de version fait partie du logiciel, la sauvegarde n'a de sens que pour se prévenir d'une panne/corruption de données.
L'intérêt c'est essentiellement l'instantanéité d'un backup par snapshot associé à la capacité de les envoyer à distance et ce même sous forme incrémentale.
Non tu peux envoyer des snapshots sous forme de fichiers. Vu que le contenu est dédupliqué les snapshots incrémentaux ne devraient pas être gros donc même si les fichiers qui finissent sur le stockage distant ne sont eux-même pas dédupliqués le bénéfice existe encore.
Le point noir de ce genre de truc dépendant des fonctionnalités comme zfs c'est qu'une fois que les données sont parties sous forme de snapshots tu ne peux pas y accéder directement. Tu dois restaurer les snaps sur un pool zfs pour avoir accès aux fichiers finaux. Ça va si tu n'as pas besoin que tes utilisateurs puissent directement demander l'accès à tel ou tel fichier individuellement.
On est d'accord que si tu dédup et chiffres dans le FS après envoi c'est dans un cas où justement tu maitrises et gère le stockage final.
Cela-dit dans un cas où tu as plus d'une poignée machines à sauvegarder en général tu as un système de backup tampon à court terme en local, donc il n'est pas inimaginable si on reprend l'exemple de zfs de dédupliquer et chiffrer sur un serveur local qui après envoie ses snapshots dans le cloud.
De toute façon la réalité c'est que la dedup n'est as forcément une solution très pertinente en terme de coût.
Pour le cas de ZFS il faut savoir que toute ce qui est dedup/chiffrement/compression se fait au niveau block et pas au niveau fichier sous ZFS donc il est tout à fait possible d'activer à la fois le chiffrement et la deduplication en même temps.
Bref il faut tester avec des jeux de données réalistes et connaitre où on veut placer le curseur entre performances (toutes les tables de dedup en mémoire) ou coût et utilisation mémoire réduite (cache sur disques rapides ssd).
Et le tout dépend des fluctuations entre prix de la ram et prix du stockage.
Cela-dit la dedup n'est pas possible que via zfs et btrfs. Il existe aussi d'autres solutions que je n'ai pas testé comme opendedup, lessfs ou permabit VDO.
Comme je le dis il y'a deux écoles. En gros plus ton infra est robuste (réseau et stockage rapide, serveurs puissant et bien dotés en ram), plus tu auras tendance à déléguer ça à la couche FS. Si par contre tu backup via du wifi, des lignes lentes et un stockage pas très rapide sur un nas lowcost tu préferas probablement faire la dedup en amont (typiquement le backup à la maison).
Il y'a deux écoles mais personnellement je préfère que mon logiciel de backup soit "bête et méchant" à ce niveau là et déléguer la fonctionnalité de deduplication à la couche FS.
[^] # Re: nuage
Posté par Psychofox (Mastodon) . En réponse au message Partage photos en plus de Facebook. Évalué à 3. Dernière modification le 28 août 2017 à 17:01.
Ça fait longtemps que je n'ai plus visité facebook mais de ce que j'en sais ils veulent le faire façon AOL/portail unique de l'utilisateur donc autant ils veulent bien qu'on partage des liens vers facebook autant synchroniser le contenu lui-même ailleurs c'est pas le genre de truc qui les intéresse. J'ai bien peur que tu ne sois bloqué entre changer les habitudes de I, J et K ou créer un compte FB pour Mamie.
Je suis étonné que I, J et K utilisent encore ce dinosaure, je croyais que tout le monde utilisais snapshat ou whatsapp pour se partager des photos maintenant.
# ça manque d'info
Posté par Psychofox (Mastodon) . En réponse au message Plus de connexion internet, pas les outils installé . Évalué à 3.
Utilisez-vous un cable ethernet ou le wifi ?
Que disent les commandes suivantes ?
ip aroutegetent hostscat /etc/resolv.confcat /etc/network/interfacescat /etc/network/interfaces.d/*[^] # Re: nuage
Posté par Psychofox (Mastodon) . En réponse au message Partage photos en plus de Facebook. Évalué à 2. Dernière modification le 28 août 2017 à 16:45.
Note que si tu t'autohéberges et que tu veux une sécurité plus forte que des urls secrètes sans que Mamie n'ait à se rappeler d'un mot de passe tu peux mettre en place une authentification à base de certificats. Faudra juste trouver moyen d'installer des certificats signés chez M, I, J et K mais les navigateurs modernes permettent maintenant une installation facile en quelques clicks. Tu choisiras une date d'expiration de certificat en fonction de la durée de vie estimée de Mamie et du nombre de fois que tu as envie de répéter la manoeuvre.
https://arcweb.co/securing-websites-nginx-and-client-side-certificate-authentication-linux/
# nuage
Posté par Psychofox (Mastodon) . En réponse au message Partage photos en plus de Facebook. Évalué à 2.
I, J et K utilisent un service nuageux, autohébergé ou non depuis lequel il peuvent partager un lien unique à la fois sur FB et sur l'email de grand maman permettant à tout un chacun d'atterir sur ladite page remplie de photo. Alors certe les photos seront potentiellement visible par n'importe qui visitant le grand nain ternet mais si l'url est générée et suffisemment longue normalement on ne peut tomber dessus sans avoir le lien au préalable (et dans le cas contraire il est toujours possible de créer un compte à mamie dans ledit nuage en question)
Ça peut être du piwigo/photoshow, mais aussi du owncloud, nextcloud, cozycloud, dropbox, google photos, imgur, flickr, et j'en passe…
J'veux dire, facebook c'est à peu près le pire media pour partager facilement des photos avec de multiples interlocuteurs et l'ui est dégueulasse.
# Ceux qui ont choisis les deux premières questions...
Posté par Psychofox (Mastodon) . En réponse au sondage Ce que je suis prêt à laisser aux GAFAM. Évalué à 1. Dernière modification le 28 août 2017 à 15:03.
…ne doivent pas beaucoup utiliser le web et l'email, où alors que en empruntant les appareils des autres et en chiffrant tous leurs mails.
[^] # Re: Les cookies
Posté par Psychofox (Mastodon) . En réponse au journal Firefox 57 - onglets contextuels et autres joyeusetés. Évalué à 6. Dernière modification le 28 août 2017 à 13:29.
T'as jamais vu les petits bouton twitter/facebook/g+/etc sur les sites qui permettent de "partager ce contenu" ? Ben ce bouton pointe sur le domaine twitter et leur permet de savoir de quel url ils sont appelés et donc quel site/contenu tu as visité.
Raison pour laquelle la bonne pratique pour éviter d'être tracker est d'utiliser une extension qui empêche de charger du contenu externe à celui que l'on visite ou de ne consulter qu'un site à la fois et de s'y déconnecter immédiatement après.
# Quelques idées
Posté par Psychofox (Mastodon) . En réponse au message Gestion centralisée d'un parc de postes de travail (300 postes). Évalué à 3. Dernière modification le 28 août 2017 à 12:03.
Le sujet est vaste.
Déploiement / gestion de configuration
Au niveau du déploiement/configuration de machines nous utilisons avec succès pour nos serveurs le couple The Foreman / Puppet. C'est la version "libre" de Redhat Satellite. Bien que ce soit conçu dans une optique serveur je ne vois pas ce qui pourrait bloquer un cas desktop.
Gestion des mises à jours
Pour les mises à jours il y'a plusieurs méthodes, il faudrait mieux connaître tes utilisateurs, leurs cas d'usage et types d'horaire de travail. Quelques méthodes:
La méthode bête et méchante :
Tu forces les maj tous les x temps avec un reboot imposé (par exemple tous les week-ends). Le corollaire c'est que :
L'avantage c'est que ça nécessite peu d'outillage. Juste de pouvoir faire éventuellement du wake-on-lan et le reste c'est de la crontab.
La méthode souple:
Tu éduques tes utilisateurs pour qu'ils lancent les maj depuis l'application dédiée sur leur desktop (celle qui annonce les maj) de temps en temps et tu forces les maj de temps en temps pour le reste du backlog (en gros les utilisateurs qui ne le feraient pas. Là il faut bien connaître ses utilisteurs et savoir s'ils sont prêt.
De toute façon c'est plus où moins la même merde sous windows.
Il existe un outil console nommé apt-dater qui permet de faciliter le check et les mises à jour de groupes de machines. Bien que son nom contient "apt" il sait maintenant gérer les distribs basées sur du redhat/suse. Dans le cas où tu utiliserais un outil comme Foreman, le plugin Katello permet aussi de gérer tout cela de façon un peu plus "enterprise friendly" (en gros c'est dans l'interface web), il peut te créer des rapports sur l'état des clients et pousser des jobs de mises à jour grouper.
Le nerf de la guerre
Vu que tu parles de ne migrer qu'1/3 du parc tu vas j'imagine garder ton AD. Ce n'est pas un problème en soit car on peut utiliser l'AD pour s'authentifier sur des machines linux. Par contre tu vas devoir gérer la cohabitation parc windows/parc linux correctement. Quid de la compatibilité des formats de fichiers ? Quid de la gestion des accès sur les partages réseaux ? Quand l'utilisateur X qui est encore sous windows envoie un lien vers un fichier de type K:\nomdesondepartement\biduletruc.doc par email à ton utilisateur Y comment celui-ci saura que K:\ correspond normalement au share Bidule sur le serveur Trucmuche ? Bref fonctionnez-vous avec des share réseaux ou utilisez-vous une GED ? Quid de la messagerie ? De mon côté je m'accomode du fonctionnement de Gnome Evolution (j'avais utilisé davmail avec kmail auparavant) pour l'accès à ma boite exchange mais il me crashe quand même régulièrement des messages comme quoi il perd la connection avec l'addressbook. Si moi je peux m'en accomoder je n'accèpterai pas ce genre de bricolage avec mes utilisateurs.
Au niveau technique il y'a plein de solutions abouties pour gérer des linux en masse. Le principal challenge c'est de faire cohabiter deux mondes.
[^] # Re: KDE presque un 10 sur 10 comme DE.
Posté par Psychofox (Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 4.
continue continue c'est vite dit.
Les commits sont assez rares, il semble qu'une seule personne bosse dessus et la dernière release remonte au mois de novembre dernier.
[^] # Re: Vieux débat (nouvelles réponses?)
Posté par Psychofox (Mastodon) . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 3. Dernière modification le 24 août 2017 à 10:32.
$ mkdir ~/spacemacs/$ git clone https://github.com/syl20bnr/spacemacs ~/spacemacs/.emacs.d
$ HOME=~/spacemacs emacs
sinon tu peux utiliser GNU stow ou d'autres alternatives pour gérer tes dotfiles.
[^] # Re: Est ce utilisable tout les jours?
Posté par Psychofox (Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 4.
Non mais j'essaye pas de te convaincre d'utiliser du linux à la place d'Haïku, je dis juste qu'il y'a moyen de faire tourner du plus léger que la distro de base avec gros environnement de bureau.
Perso sur les vieilles machines j'aime bien mettre du openbsd. C'est hyper vite installé, à peu près tous les applis que je veux sont dispos, c'est facile à maintenir et à comprendre et ça supporte à peu près n'importe quoi à partir du intel 486.
[^] # Re: Est ce utilisable tout les jours?
Posté par Psychofox (Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 5.
En même temps tu prends ton linux de tous les jours et tu démarre une session flux/openbox au lieu de kde ou gnome et c'est déjà le jour et la nuit en terme de ressenti.
Après ça va plus dépendre des applications que tu fais tourner au dessus mais j'imagine qu'on auras beau avoir un OS léger avec Haïku le jour où on porte une application comme libreoffice ou un navigateur bien moderne tu verras que la différence n'est pas aussi grand qu'elle n'y parait.
[^] # Re: Est ce utilisable tout les jours?
Posté par Psychofox (Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Ce n'était pas le cas à l'époque où ce pc a été créé mais à notre époque javascript&co oblige c'est devenu une des activitées demandant le plus de ressources.
Si tu as une autre machine à côté sur laquelle tu peux mettre un serveur SPICE, j'en ferais plutôt un thin client à base de mini distro style tinycore linux ou puppy linux.
[^] # Re: Slimbook
Posté par Psychofox (Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 2. Dernière modification le 22 août 2017 à 08:09.
Si tu checks sur le store tu verras que l'écran est disponible en finition matte ou brillante. Aucune idée de la qualité mais il y'a quelques articles à leur propos sur le net.
Pour répondre également à eingrossfilou la version actuelle de kde fournie avec kde neon est la 5.10. Par contre en dessous c'est une ubuntu LTS donc déjà la vieillissante 16.04. Si tu veux des packages autres que kde bleeding edge il faudra donc passer par des backports, ppa, snaps, dépôts externes ou autre.
[^] # Re: KDE presque un 10 sur 10 comme DE.
Posté par Psychofox (Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 3.
Il a mentionné avoir testé sous KDE neon, c'est la distrib qui reçoit justement les corrections de bugs kde les plus vite normalement. Ce sont plutôt les nouveaux bugs qu'on recevrait en premier ! Mais comme je l'ai dit dans mon post plus haut il y'a un fossé entre la kde neon user edition, qui m'a apparu très stable et la version git-stable (je n'ose même pas imaginer la git-unstable).
[^] # Re: KDE presque un 10 sur 10 comme DE.
Posté par Psychofox (Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 2.
J'ai deux laptops sous kde neon, une en version "user edition" avec la dernière release officielle de kde5, l'autre installée avec la "developer edition git-stable". La première fonctionne très bien mais la seconde est à peine utilisable. En gros un apt upgrade sur deux tu te retrouves dans une version tellement instable de plasmashell que si tu veux bosser t'as intérêt à le killer parce qu'il te bouffe tout ton cpu. Ça perd vite de son intérêt.
Du coup je vais virer ce kde neon developer-edition, ça n'a effectivement d'intérêt que pour le dev kde qui veut débugger.
[^] # Re: Le spoiler...
Posté par Psychofox (Mastodon) . En réponse au journal [Btrfs et openSUSE] Épisode 1 : sous‐volumes, snapshots et rollbacks. Évalué à 4.
Je pense qu'il y'en a deux trois qui sont vexés parce qu'ils n'avaient encore rien compris au film 20ans après.
[^] # Re: Le spoiler...
Posté par Psychofox (Mastodon) . En réponse au journal [Btrfs et openSUSE] Épisode 1 : sous‐volumes, snapshots et rollbacks. Évalué à -1.
En même temps l'intérêt de la blague sur les spoilers du Sixième Sens c'est justement que dès les 5 premières minutes tout le monde en connaissait la fin.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . En réponse au journal Obnam est abandonné. Évalué à 3.
Oui parce que c'est plus commode et que cela permet en même temps de valider l'intégrité des données. Mais ce n'est pas obligatoire en tant que tel si le seul but est de pouvoir faire du disaster recovery par exemple.
Faut voir ça comme une méthode d'externalisation des données à moindre coût, un peu comme quand on dupliquait des bandes magnétiques et qu'on les envoyait sur un autre site, un coffre fort de banque ou autre. C'est aussi valable pour de l'archivage. Quand t'envoies tes données sur Amazon Glacier par exemple, tu ne t'attends pas à pouvoir les restaurer à la minute non plus.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . En réponse au journal Obnam est abandonné. Évalué à 2.
J'ai utilisé ce genre de méthode sur des machines solaris (mais sans la partie chiffrement) dans divers cas :
-dumps de bases de données
-sauvegarde de données alfresco
Faut savoir que des grosses instances alfresco, ça peut vite représenter des millions de fichiers avec beaucoup qui font moins de 1k. Avec un accès au fichier "standard" un backup est beaucoup trop long (faut oublier de faire un ls aussi). Du coup les sauvegardes à base de snapshot et d'envoi de snapshot sont très pertinentes dans ce cas. Le corrolaire c'est que tu ne peux pas restaurer un fichier individuellement mais c'est de toute façon pas un cas qui s'applique étant donné que la gestion de version fait partie du logiciel, la sauvegarde n'a de sens que pour se prévenir d'une panne/corruption de données.
L'intérêt c'est essentiellement l'instantanéité d'un backup par snapshot associé à la capacité de les envoyer à distance et ce même sous forme incrémentale.
Quelques autres exemples de cas d'usages, scripts ou outils se basant dessus :
http://royal.pingdom.com/2013/06/04/zfs-backup/
https://www.grendelman.net/wp/fast-frequent-incremental-zfs-backups-with-zrep/
http://mij.oltrelinux.com/devel/zfsbackup/
http://www.rsync.net/products/zfsintro.html
http://www.daveeddy.com/2015/12/05/automatic-zfs-snapshots-and-backups/
http://www.znapzend.org/
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . En réponse au journal Obnam est abandonné. Évalué à 2.
Non tu peux envoyer des snapshots sous forme de fichiers. Vu que le contenu est dédupliqué les snapshots incrémentaux ne devraient pas être gros donc même si les fichiers qui finissent sur le stockage distant ne sont eux-même pas dédupliqués le bénéfice existe encore.
Le point noir de ce genre de truc dépendant des fonctionnalités comme zfs c'est qu'une fois que les données sont parties sous forme de snapshots tu ne peux pas y accéder directement. Tu dois restaurer les snaps sur un pool zfs pour avoir accès aux fichiers finaux. Ça va si tu n'as pas besoin que tes utilisateurs puissent directement demander l'accès à tel ou tel fichier individuellement.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . En réponse au journal Obnam est abandonné. Évalué à 2.
On est d'accord que si tu dédup et chiffres dans le FS après envoi c'est dans un cas où justement tu maitrises et gère le stockage final.
Cela-dit dans un cas où tu as plus d'une poignée machines à sauvegarder en général tu as un système de backup tampon à court terme en local, donc il n'est pas inimaginable si on reprend l'exemple de zfs de dédupliquer et chiffrer sur un serveur local qui après envoie ses snapshots dans le cloud.
De toute façon la réalité c'est que la dedup n'est as forcément une solution très pertinente en terme de coût.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . En réponse au journal Obnam est abandonné. Évalué à 3.
Pour le cas de ZFS il faut savoir que toute ce qui est dedup/chiffrement/compression se fait au niveau block et pas au niveau fichier sous ZFS donc il est tout à fait possible d'activer à la fois le chiffrement et la deduplication en même temps.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . En réponse au journal Obnam est abandonné. Évalué à 3. Dernière modification le 16 août 2017 à 12:35.
Sous ZFS le coût en terme de mémoire est de 320Bytes par block. Il faut connaître le nombre de block utilisé par les données, tout en sachant que sous ZFS la taille de block est dynamique :
http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html
http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe
Bref il faut tester avec des jeux de données réalistes et connaitre où on veut placer le curseur entre performances (toutes les tables de dedup en mémoire) ou coût et utilisation mémoire réduite (cache sur disques rapides ssd).
Et le tout dépend des fluctuations entre prix de la ram et prix du stockage.
Cela-dit la dedup n'est pas possible que via zfs et btrfs. Il existe aussi d'autres solutions que je n'ai pas testé comme opendedup, lessfs ou permabit VDO.
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . En réponse au journal Obnam est abandonné. Évalué à 3.
Comme je le dis il y'a deux écoles. En gros plus ton infra est robuste (réseau et stockage rapide, serveurs puissant et bien dotés en ram), plus tu auras tendance à déléguer ça à la couche FS. Si par contre tu backup via du wifi, des lignes lentes et un stockage pas très rapide sur un nas lowcost tu préferas probablement faire la dedup en amont (typiquement le backup à la maison).
[^] # Re: Pas trop étonné
Posté par Psychofox (Mastodon) . En réponse au journal Obnam est abandonné. Évalué à 2.
Il y'a deux écoles mais personnellement je préfère que mon logiciel de backup soit "bête et méchant" à ce niveau là et déléguer la fonctionnalité de deduplication à la couche FS.