Rappelons quand même que dans le cas cité dans le journal l'entreprise paye à Amazon, Google, Bing… Donc le business model est un peu différent via un intermédiaire mais au final ce sont toujours les mêmes qui récupèrent l'argent.
Tant que tout le monde est content (le client final, l'intermédiaire et le moteur de recherche final), est-ce que cela est un soucis ?
Et que sans "tracking" (historique des recherches) on a des résultats forcément moins pertinents car génériques et pas adaptés à nous, je n'ai pas testé le produit du journal mais je connais la différence entre Google avec mon compte et Google en navigation privée. Est-ce que la qualité serait suffisante pour les gens aillant pris l'habitude de réponse personnalisée?
Je crois que l'approche est différente: c'est à toi de personnaliser le moteur en blacklistant certains domaines par exemple.
Mais de mon côté, même sans personnaliser je trouve les résultats plus pertinents qu'avec Google (avec historique ou pas).
Il faut essayer pour se faire un avis, pour le moment c'est gratuit…
Il faut aussi considérer qu'une partie de la population ne payera pas, quel que soit le prix, et cela même si elle en a largement les moyens.
Vous vous rappelez les $1 par an de Whatsapp ?
Mais débattre sur le prix n'est pas très intéressant pour le moment, car le projet est encore très jeune. Si ce prix là leur permet de se lancer et de progresser à petits pas, tant mieux pour eux !
Certaines personnes sont prêtes à payer plus cher pour avoir un meilleur service qu'un modèle gratuit avec pub (Deezer/Spotify avec ou sans pub, Netflix/Disney+, etc.). À chacun de faire ses choix et de mettre ses sous là où cela compte.
On peut certes regretter que cela ne soit pas accessible à plus de monde, mais c'est rafraîchissant de voir une entreprise avec cette approche (petite équipe, résultats de qualité, focalisé sur l'utilisateur et pas sur la croissance à tout prix au détriment de la rentabilité).
Pour l'anecdote, j'ai trouvé un bug et envoyé un email: dans les 5 minutes, le fondateur m'a répondu. C'est peut-être un hasard mais c'est très sympathique !
Oui c'est par mois.
À titre de comparaison, Fastmail c'est $5/mois et NextDNS c'est $2/mois, pour des services que l'on trouve gratuitement par ailleurs.
J'imagine que c'est dégressif et qu'il y aura des formules "familles" et des réductions si tu payes un an d'un coup, mais cela donne une idée.
Je trouve cela aussi relativement cher, mais:
je suis de plus insatisfait par Google et je n'ai pas trouvé d'alternatives
j'aime bien être le client et payer pour le service autrement que par mon « temps de cerveau disponible »
les résultats de Kagi sont vraiment bons et me font gagner du temps
Donc il faut que je pèse les patates entre le gain confort/temps et le coût.
Mais sinon est-ce que quelqu'un a trouvé un moteur de recherche qui fonctionne mieux que Google (oui je sais c'est subjectif) ?
DuckDuckGo c'est mieux sur certains points (avec les !Bang) mais en général je trouve les résultats moins bons que Google.
Dans mon cas d'utilisation, j'utilise jpeg-archive pour archiver des photos, donc je vise une bonne résolution.
J'avais trouvé que jpeg-archive + option smallfry/accurate/quality high donnait un rendu qui est exactement identique à l'image originale donc c'était impeccable pour moi.
Le plus important pour moi est d'avoir quelque qui:
- marche
- soit libre
- soit bien intégrée à ma distribution (Debian)
Si Mozjpeg et YOGA permettent de faire mieux, j'en suis ravi !
Merci beaucoup c'est très instructif ! Je vais pouvoir changer vers Mozjpeg….
Les options que tu utilises de Mozjpeg, c'est pour de la visualisation web ? Est-ce que tu n'aurais pas aussi bon set d'option pour du rendu photographique (pour impression par exemple) ?
Pour ma part j'utilise jpeg-archive avec l'option smallfry
Smallfry est très efficace mais attention:
Note: The SmallFry algorithm may be patented so use with caution.
Honnêtement je n'ai jamais vu de différence visuelle entre avant et après et le gain est souvent de l'ordre de plus de 70% pour les jpegs provenant de mon appareil photo APS-C.
Oui tu fais comme je l'avais imaginé: tu mets tes photos à part et c'est donc plus compliqué d'y accéder.
Sans parler du fait que tu maintiens deux processus de sauvegardes différents (rsync+tarsnap).
Je ne doute pas que cela marche bien dans ton cas si tu as la discipline et la compétence derrière.
Mais imagine le cas d'une famille où tout le monde stocke n'importe où au petit bonheur. Tu te vois expliquer qu'il faut stocker les photos ici et les vidéo là et les fichier ici ?
Tu peux aussi tenter le coup dans une entreprise : dans mon entreprise, on avait le même principe que toi (un disque réseau pour les fichiers importants, un répertoire local pour les fichiers temporaires, etc.). Au final tu as toujours des utilisateurs qui râlent car ils ont perdu des semaines de travail car ils ont pas stocké au bon endroit.
Du coup j'ai pris l'option radicale: chacun gère ses appareils comme il veut. Tous les appareils sont sauvegardés sur un NAS où un processus de déduplication a lieu et un contrôle d'intégrité (Btrfs scrub). Le NAS en lui-même est sauvegardé sur un site distant.
Pour l'instant tout fonctionne bien, mais il est vrai que je me repose beaucoup sur Btrfs.
Que veux-tu dire par réécrire ?
Les données sont sur mon disque et je n'y touche pas. Elles sont prises en compte lors de la sauvegarde de données c'est tout.
La plupart du temps, le méchanisme de sauvegarde les ignore car elles n'ont pas changé (sauvegarde incrémentale).
C'est seulement lors d'une sauvegarde complète, qu'elles sont lues.
Quelle solution tu préconises pour gérer des photos ?
Je suppose que je peux les mettre sur un disque à part avec des sommes par2, mais ça veut dire que:
- c'est plus compliqué pour y accéder
- il faut que je fasse manuellement (ou via un script supplémentaire) le contrôle et la correction
- il faut que je gère la sauvegarde de ce disque séparemment
Déjà la sauvegarde c'est pénible, donc le but c'est de rendre le truc le plus simple et automatisé possible.
J'ai des milliers de photos que je regarde seulement de temps en temps.
Il peut se passer des années avant que je regarde de nouveau les photos de 2003 par exemple, mais j'aime bien les avoir sous la main.
Idem pour des vieux fichiers (bulletin de paie par exemple) que je ne regarde jamais mais dont on peut avoir besoin.
Pour moi c'est la cause la plus probable hormis les boulettes utilisateurs/administrateurs.
Le feu, la foudre, les explositions, les cambriolages, c'est somme toute assez rare (quoique pour les cambriolages, cela dépend de là où l'on vit).
Par contre les corruptions de données, cela m'arrive régulièrement.
Je ne sais pas si c'est parce que je n'ai pas de chance ou si c'est parce que je teste régulièrement (bah oui si on ne regarde pas, il n'y a pas de problème…).
Disque endommagé, câble data défectueux, câble power défecteux: j'ai tout eu.
Expérience vécue: j'avais de bons disques mais des câbles endommagés.
Au final j'avais beaucoup de corruption de données (non corrigé par le disque du coup).
Si je ne teste pas mon filesystem (avec scrub) et que je fais uniquement des sauvegardes, comment je fais pour ne pas perdre des données ?
Tu peux aussi utiliser ZFS si tu veux quelque chose de plus mature mais avec le même principe…
Mais oui Btrfs n'est pas fini, loin de là.
Cependant si tu restes dans du simple RAID1, je n'ai pas vu beaucoup de soucis.
Le plus embêtant c'est quand il faut réparer, dans ce cas la meilleure solution est:
- le RAID1 te permet de réparer avec un simple scrub
- si ça ne marche pas, balancer le disque dur et reconstruire le RAID
Essayer de réparer un Btrfs (hormis avec scrub), il faut avoir le coeur solide.
Btrfs peut être configuré pour détecter la corruption de données: par exemple en RAID1 tu peux stocker deux fois les données et les métadonnées.
Si tu lances tous les soirs une vérification (scrub), tu auras le résumé (et la correction !) des données corrompues.
C'est une preuve indirecte que tes disques flanchent.
Bien entendu le mieux c'est de détecter plus en amont (smartctl, badblocks et compagnie…)
Attention la déduplication par bloc et les snapshots, ce n'est pas la même chose.
La déduplication permet surtout de limiter l'effet de fichiers ou blocs dupliqués. Typiquement si tu crées deux fichiers exactement identiques, la déduplication (online ou offline) va trouver ces deux fichiers et ne va en stocker réeelement qu'un seul.
Par contre c'est vrai que si tu ne changes que légèrement un fichier, seul le bloc impacté est mis à jour dans le snapshot (vu que le snapshot opère au nivau du bloc si je me souviens bien).
Avec Btrfs, le mieux c'est de lancer un processus de déduplication avant de faire le snapshot.
Mais attention dans ce cas là, car si tu as un fichier qui est dédupliqué des centaines de fois, tu n'as plus qu'une copie de ce fichier (donc s'il est corrompu…).
Raison pour laquelle j'utilise RAID avec Btrfs…
Il semblerait effectivement que Piwigo ne soit pas le seul touché.
Vu les sites touchés (Wordpress et compagnie), je penche de mon côté sur un problème dans les bibliothèques PHP qu'utilisent Piwigo.
L'investigation devrait être intéressante, je vais suivre le bogue !
j'en ai parlé plus haut dans mes commentaires, je n'ai malheureusement pas réussi à faire marcher ce piwigo-privacy. Si j'ai le courage, j'essaierai de nouveau de faire marcher cette méthode, mais ce serait bien si c'était directement intégré à Piwigo.
Après il faut relativiser ce problème. Si on connaît le chemin d'un fichier, c'est normalement qu'on y a eu accès de façon explicite (si on peut trouver l'url de vos fichiers en la devinant, il faut résoudre le problème en amont). Le problème est donc que la personne peut "partager" l'url avec qqun d'autre. Cette personne pourrait tout aussi bien copier votre photo sur Facebook ! C'est donc une question de confiance envers les personnes avec qui l'on partage ses contenus privés, et pour cela Piwigo ne peut pas faire grand chose.
C'est plus un problème de sécurité que de vie privée (sécurité par obscurité de l'URL).
Pour moi tous les accès, quels qu'il soient (URL direct, indirect, API, …) doivent transiter par le gestionnaire de permissions.
Je ne sais pas comment marche NextCloud/OwnCloud, Salut à Toi, Seafile et autre concurrents. Mais j'ai l'impression que cela marche vite et bien et que ce problème d'URL d'accès direct à l'image n'existe pas.
Enfin je suppose que vous avez déjà réfléchi longuement à ce soucis et que si vous ne l'avez pas déjà implémenté, c'est que vous avez vos raisons (c'est pas vraiment une fonctionnalité demandées par vos utilisateurs payant par exemple).
Mais pour ma part j'ai trouvé un moyen de contournement, donc pour l'instant ça va.
Effectivement cela me semble un gros trou de sécurité et trouver la faille ne semble pas si facile…
Cela ne va pas atténuer mon préjugé sur la sécurité des applis en PHP… et je vais continuer à mettre mon Piwigo derrière un HTTP Basic Access Authentication.
Sinon je viens de tester une nouvelle fois et si on connaît le nom de l'album et le nom du fichier d'une photo, n'importe qui peut toujours accéder à la photo, sans avoir besoin de se connecter.
C'était un problème remonté en 2012: https://piwigo.org/forum/viewtopic.php?id=20372&p=1
Donc Piwigo c'est bien mais faites très attention à la sécurité et à la confidentialité…
Sa question est pertinente, car tout le monde ne respecte pas le robots.txt.
Pour ma part, j'ai ajouté une couche d'HTTP Basic Access Authentication pour empêcher ce genre d'accès.
Du coup dans mon email, je n'ai que le lien unique (les identifiants ayant été envoyé avec un email précédent).
Ce n'est pas l'idéal, mais cela permet de se protéger contre le scan et accès automatique.
Je ne sais pas ce qu'est le "truc de l'URL semi-privée". En revanche je peux te proposer 2 solutions :
URL semi-privée, c'est lié au fait que ce n'est pas très sécurisé. Comme cité plus bas, si tes emails sont scannés (genre si ton correspondant est sur mail.ru ou autre), tes photos se retrouvent indexées.
Seafile par exemple contourne un peu le problème en proposant aussi de protéger avec un mot de passe.
Donc il ne suffit pas d'avoir le lien, il faut aussi le mot de passe.
tu créées tes utilisateurs, tu leur donnes la permission sur ton album privé, puis tu les notifies (onglet "notification" de la page d'administration de l'album). Ils recevront un email avec un lien avec une clef d'auto-identification. Du coup, ils n'auront pas besoin de s'identifier, ça se fera tout seul.
Oui c'est ce que j'utilise. J'avais aussi essayé avec un utilisateur générique mais cela n'avait jamais bien fonctionné sans que je sache bien pourquoi (je n'ai pas réussi à déboguer et cela semble marcher pour les autres). Le problème que je rencontre c'est qu'il faut que j'envoie un faux email pour récupérer le lien car je souhaite envoyer moi-même le lien.
tu utilises le plugin Share Album. En gros il fait le travail de création d'utilisateur et d'assignation des permissions à ta place et te donnes juste un lien à partager (qui inclut une clef d'identification)
C'est intéressant, le plugin doit être nouveau car je ne l'avais pas repéré il y 2 ans quand je me suis intéressé à la question. Merci pour l'astuce !
c'est en PHP et il faut bien suivre les mises à jour de sécurité.
A mon avis, il faut surtout bien suivre les mises à jour des applications web que tu utilises (Piwigo, Wordpress, etc.). Je ne dis pas que les alertes de sécurité de PHP sont négligeables, mais que sur une échelle de risque, il y a plus risqué. Et puis il suffit de suivre les mises à jour de ta distribution Linux :-)
Sans vouloir trop m'étendre, il y a plusieurs raisons pour laquelle j'ai rajouté une couche d'HTTP Basic Access Authentication :
- Il me semble que le niveau de sécurité/confidentialité de Piwigo a un soucis (https://piwigo.org/forum/viewtopic.php?id=20372&p=3). Du coup j'avais essayé de configurer pour empêcher l'accès aux photos sans être connecté (https://github.com/yonjah/piwigo_privacy) mais cela n'avait pas fonctionné. De guerre lasse, j'ai utilisé l'HTTP Basic Access Authentication.
- J'ai moyennement confiance dans la sécurité des applications PHP (oui c'est un préjugé et j'y travaille)
- Je n'ai pas beaucoup de temps pour la maintenance de mon système, et je suis Piwigo seulement de temps en temps. Donc je ne suis pas très réactif quand une nouvelle version de Piwigo est disponible pour l'installer (par contre j'ai activé l'installation automatique des mises à jour de sécurité sur ma distribution).
Bref le HTTP Basic Access Authentication c'est le garde-fou du pauvre.
Pour les caractères spéciaux, tu peux modifier la configuration locale pour les autoriser. Mais moi à ta place, j'utiliserais plutôt l'outil Piwigo Remote Sync qui prend ton arborescence locale et la synchronise, via API, à ton Piwigo. Tu as le meilleur des deux mondes :-)
J'avoue que je suis très vieille école sur le problème de la synchronisation et je suis très attaché à rsync. Cela permet de configurer à volonté la synchronisation. J'ai par exemple établie des règles pour ne pas synchroniser certaines photos. Et si je dois interrompre la synchronisation ou la reprendre, j'ai 100% confiance en rsync de bien optimiser la reprise et de ne pas corrompre de fichiers. Je doute malheureusement que Piwigo Remote Sync soit aussi flexible.
Concernant les applis mobiles. S'il y a une application iOS officielle, super bien maintenue et très active en terme d'évolution (merci à Eddy pour son boulot), malheureusement il n'y a pas encore d'application Android officielle sur le Play Store. PiwigoClient est une application totalement indépendante (d'ailleurs ils n'ont pas le droit d'utiliser le mot "Piwigo", c'est une marque déposée) et si elle marche tant mieux, mais nous n'y sommes pas associés. La bonne nouvelle, c'est que l'appli Piwigo officielle pour Android, après plusieurs années d'hibernation, se réveille et devrait bientôt arriver sur le Store :-)
L'appli officielle iOS est top. L'appli Piwigoclient sous Android est aussi très bien et l'auteur très sympa. Ce serait dommage de lui causer des soucis à cause du nom. À noter qu'il a intégré le mode optionnel Masonry layout qui permet d'optimiser l'affichage des photos de manières élégantes (et pas dispo sous iOS).
J'en profite pour poser la question de savoir pourquoi les accès via les applis mobiles ne sont pas enregistrés dans l'historique de Piwigo ? C'est bien dommage…
En tout cas ton intervention ne fait que renforcer mon impression que l'équipe Piwigo est vraiment dynamique et sympathique !
Il faudrait faire un journal sur le sujet !
Partager simplement ses photos et vidéos, c'est un besoin très courant, donc si tu as réussi à monter quelque chose qui soit simple et agréable à utiliser, cela devrait intéresser les utilisateurs.
Depuis que j'utilise Piwigo, je dois cependant noter que c'est loin d'être si facile.
Entre les problèmes de navigateur ou système d'exploitation, avoir quelque chose de responsive mais qui optimise bien l'espace, avoir des apps disponibles sur iOS/Android, etc.
C'est quand même beaucoup de boulot !
[^] # Re: Coquille?
Posté par SaintGermain . En réponse au journal Kagi: une alternative crédible à Google Search ?. Évalué à 2.
Tant que tout le monde est content (le client final, l'intermédiaire et le moteur de recherche final), est-ce que cela est un soucis ?
Je crois que l'approche est différente: c'est à toi de personnaliser le moteur en blacklistant certains domaines par exemple.
Mais de mon côté, même sans personnaliser je trouve les résultats plus pertinents qu'avec Google (avec historique ou pas).
Il faut essayer pour se faire un avis, pour le moment c'est gratuit…
[^] # Re: Coquille?
Posté par SaintGermain . En réponse au journal Kagi: une alternative crédible à Google Search ?. Évalué à 6.
Il faut aussi considérer qu'une partie de la population ne payera pas, quel que soit le prix, et cela même si elle en a largement les moyens.
Vous vous rappelez les $1 par an de Whatsapp ?
Mais débattre sur le prix n'est pas très intéressant pour le moment, car le projet est encore très jeune. Si ce prix là leur permet de se lancer et de progresser à petits pas, tant mieux pour eux !
Certaines personnes sont prêtes à payer plus cher pour avoir un meilleur service qu'un modèle gratuit avec pub (Deezer/Spotify avec ou sans pub, Netflix/Disney+, etc.). À chacun de faire ses choix et de mettre ses sous là où cela compte.
On peut certes regretter que cela ne soit pas accessible à plus de monde, mais c'est rafraîchissant de voir une entreprise avec cette approche (petite équipe, résultats de qualité, focalisé sur l'utilisateur et pas sur la croissance à tout prix au détriment de la rentabilité).
Pour l'anecdote, j'ai trouvé un bug et envoyé un email: dans les 5 minutes, le fondateur m'a répondu. C'est peut-être un hasard mais c'est très sympathique !
[^] # Re: Coquille?
Posté par SaintGermain . En réponse au journal Kagi: une alternative crédible à Google Search ?. Évalué à 6. Dernière modification le 10 janvier 2022 à 23:23.
Oui c'est par mois.
À titre de comparaison, Fastmail c'est $5/mois et NextDNS c'est $2/mois, pour des services que l'on trouve gratuitement par ailleurs.
J'imagine que c'est dégressif et qu'il y aura des formules "familles" et des réductions si tu payes un an d'un coup, mais cela donne une idée.
Je trouve cela aussi relativement cher, mais:
Donc il faut que je pèse les patates entre le gain confort/temps et le coût.
Mais sinon est-ce que quelqu'un a trouvé un moteur de recherche qui fonctionne mieux que Google (oui je sais c'est subjectif) ?
DuckDuckGo c'est mieux sur certains points (avec les !Bang) mais en général je trouve les résultats moins bons que Google.
[^] # Re: Par rapport à la concurrence ?
Posté par SaintGermain . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 2.
Merci bien !
Dans mon cas d'utilisation, j'utilise jpeg-archive pour archiver des photos, donc je vise une bonne résolution.
J'avais trouvé que jpeg-archive + option smallfry/accurate/quality high donnait un rendu qui est exactement identique à l'image originale donc c'était impeccable pour moi.
Le plus important pour moi est d'avoir quelque qui:
- marche
- soit libre
- soit bien intégrée à ma distribution (Debian)
Si Mozjpeg et YOGA permettent de faire mieux, j'en suis ravi !
Merci pour tes expérimentations !
[^] # Re: Par rapport à la concurrence ?
Posté par SaintGermain . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 2.
Merci beaucoup c'est très instructif ! Je vais pouvoir changer vers Mozjpeg….
Les options que tu utilises de Mozjpeg, c'est pour de la visualisation web ? Est-ce que tu n'aurais pas aussi bon set d'option pour du rendu photographique (pour impression par exemple) ?
Merci !
[^] # Re: Par rapport à la concurrence ?
Posté par SaintGermain . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 3.
Je n'ai pas bien compris la séparation des fonctionnalités entre jpeg-archive et mozjpeg: où exactement est implémenté l'algorithme smallfry ?
[^] # Re: Par rapport à la concurrence ?
Posté par SaintGermain . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 4.
Pour ma part j'utilise jpeg-archive avec l'option smallfry
Smallfry est très efficace mais attention:
Honnêtement je n'ai jamais vu de différence visuelle entre avant et après et le gain est souvent de l'ordre de plus de 70% pour les jpegs provenant de mon appareil photo APS-C.
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 2.
Oui tu fais comme je l'avais imaginé: tu mets tes photos à part et c'est donc plus compliqué d'y accéder.
Sans parler du fait que tu maintiens deux processus de sauvegardes différents (rsync+tarsnap).
Je ne doute pas que cela marche bien dans ton cas si tu as la discipline et la compétence derrière.
Mais imagine le cas d'une famille où tout le monde stocke n'importe où au petit bonheur. Tu te vois expliquer qu'il faut stocker les photos ici et les vidéo là et les fichier ici ?
Tu peux aussi tenter le coup dans une entreprise : dans mon entreprise, on avait le même principe que toi (un disque réseau pour les fichiers importants, un répertoire local pour les fichiers temporaires, etc.). Au final tu as toujours des utilisateurs qui râlent car ils ont perdu des semaines de travail car ils ont pas stocké au bon endroit.
Du coup j'ai pris l'option radicale: chacun gère ses appareils comme il veut. Tous les appareils sont sauvegardés sur un NAS où un processus de déduplication a lieu et un contrôle d'intégrité (Btrfs scrub). Le NAS en lui-même est sauvegardé sur un site distant.
Pour l'instant tout fonctionne bien, mais il est vrai que je me repose beaucoup sur Btrfs.
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 2.
Que veux-tu dire par réécrire ?
Les données sont sur mon disque et je n'y touche pas. Elles sont prises en compte lors de la sauvegarde de données c'est tout.
La plupart du temps, le méchanisme de sauvegarde les ignore car elles n'ont pas changé (sauvegarde incrémentale).
C'est seulement lors d'une sauvegarde complète, qu'elles sont lues.
Quelle solution tu préconises pour gérer des photos ?
Je suppose que je peux les mettre sur un disque à part avec des sommes par2, mais ça veut dire que:
- c'est plus compliqué pour y accéder
- il faut que je fasse manuellement (ou via un script supplémentaire) le contrôle et la correction
- il faut que je gère la sauvegarde de ce disque séparemment
Déjà la sauvegarde c'est pénible, donc le but c'est de rendre le truc le plus simple et automatisé possible.
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 2.
J'ai des milliers de photos que je regarde seulement de temps en temps.
Il peut se passer des années avant que je regarde de nouveau les photos de 2003 par exemple, mais j'aime bien les avoir sous la main.
Idem pour des vieux fichiers (bulletin de paie par exemple) que je ne regarde jamais mais dont on peut avoir besoin.
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 2.
Pour moi c'est la cause la plus probable hormis les boulettes utilisateurs/administrateurs.
Le feu, la foudre, les explositions, les cambriolages, c'est somme toute assez rare (quoique pour les cambriolages, cela dépend de là où l'on vit).
Par contre les corruptions de données, cela m'arrive régulièrement.
Je ne sais pas si c'est parce que je n'ai pas de chance ou si c'est parce que je teste régulièrement (bah oui si on ne regarde pas, il n'y a pas de problème…).
Disque endommagé, câble data défectueux, câble power défecteux: j'ai tout eu.
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 2.
Expérience vécue: j'avais de bons disques mais des câbles endommagés.
Au final j'avais beaucoup de corruption de données (non corrigé par le disque du coup).
Si je ne teste pas mon filesystem (avec scrub) et que je fais uniquement des sauvegardes, comment je fais pour ne pas perdre des données ?
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 3.
Ben tu veux faire comment pour s'assurer que ça marche sans regarder ?
Sinon c'est un peu le disque dur de Schrödinger: p'tet bien que ça marche, p'tet bien que ça marche pas..
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 3.
Tu peux aussi utiliser ZFS si tu veux quelque chose de plus mature mais avec le même principe…
Mais oui Btrfs n'est pas fini, loin de là.
Cependant si tu restes dans du simple RAID1, je n'ai pas vu beaucoup de soucis.
Le plus embêtant c'est quand il faut réparer, dans ce cas la meilleure solution est:
- le RAID1 te permet de réparer avec un simple scrub
- si ça ne marche pas, balancer le disque dur et reconstruire le RAID
Essayer de réparer un Btrfs (hormis avec scrub), il faut avoir le coeur solide.
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 3.
Btrfs peut être configuré pour détecter la corruption de données: par exemple en RAID1 tu peux stocker deux fois les données et les métadonnées.
Si tu lances tous les soirs une vérification (scrub), tu auras le résumé (et la correction !) des données corrompues.
C'est une preuve indirecte que tes disques flanchent.
Bien entendu le mieux c'est de détecter plus en amont (smartctl, badblocks et compagnie…)
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 4.
Attention la déduplication par bloc et les snapshots, ce n'est pas la même chose.
La déduplication permet surtout de limiter l'effet de fichiers ou blocs dupliqués. Typiquement si tu crées deux fichiers exactement identiques, la déduplication (online ou offline) va trouver ces deux fichiers et ne va en stocker réeelement qu'un seul.
Par contre c'est vrai que si tu ne changes que légèrement un fichier, seul le bloc impacté est mis à jour dans le snapshot (vu que le snapshot opère au nivau du bloc si je me souviens bien).
Avec Btrfs, le mieux c'est de lancer un processus de déduplication avant de faire le snapshot.
Mais attention dans ce cas là, car si tu as un fichier qui est dédupliqué des centaines de fois, tu n'as plus qu'une copie de ce fichier (donc s'il est corrompu…).
Raison pour laquelle j'utilise RAID avec Btrfs…
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . En réponse au journal Sauvegarde de données. Évalué à 3.
Je me souviens d'une discussion ici même où je luttais pour faire comprendre que BTRFS en RAID 1 permet de lutter contre la corruption de données :
https://linuxfr.org/users/saintgermain/journaux/gestion-de-versions-et-sauvegarde-de-donnees
C'est vraiment pas évident pour tout le monde…
La conclusion que j'en ai tirée, c'est que parler de RAID et de sauvegarde dans le même texte, c'est s'exposer à des remarques violentes.
[^] # Re: Piwigo et Cialis
Posté par SaintGermain . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 4.
Je ne suis pas expert en sécurité mais à la vue des résultats:
https://www.google.com/search?q=photographie+cialis
Il semblerait effectivement que Piwigo ne soit pas le seul touché.
Vu les sites touchés (Wordpress et compagnie), je penche de mon côté sur un problème dans les bibliothèques PHP qu'utilisent Piwigo.
L'investigation devrait être intéressante, je vais suivre le bogue !
[^] # Re: Piwigo et Cialis
Posté par SaintGermain . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 3.
Le lien vers le ticket Github:
https://github.com/Piwigo/Piwigo/issues/827
En premier commentaire, c'est l'April:
https://agir.april.org/issues/2861
Quelque part je doute que l'April utilise Windows derrière, mais je peux me tromper…
[^] # Re: Piwigo et Cialis
Posté par SaintGermain . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 2.
J'avais bien repéré le lien que vous donnez.
Mais j'ai été un peu découragé par la complexité de la chose et par les nombreuses réserves/contraintes :
Et en bas de la plage, j'ai relevé le dernier commentaire par yonjah qui a développé une méthode plus globale :
https://ca.non.co.il/index.php/securing-private-piwigo-albums/
https://github.com/yonjah/piwigo-privacy
j'en ai parlé plus haut dans mes commentaires, je n'ai malheureusement pas réussi à faire marcher ce piwigo-privacy. Si j'ai le courage, j'essaierai de nouveau de faire marcher cette méthode, mais ce serait bien si c'était directement intégré à Piwigo.
C'est plus un problème de sécurité que de vie privée (sécurité par obscurité de l'URL).
Pour moi tous les accès, quels qu'il soient (URL direct, indirect, API, …) doivent transiter par le gestionnaire de permissions.
Je ne sais pas comment marche NextCloud/OwnCloud, Salut à Toi, Seafile et autre concurrents. Mais j'ai l'impression que cela marche vite et bien et que ce problème d'URL d'accès direct à l'image n'existe pas.
Enfin je suppose que vous avez déjà réfléchi longuement à ce soucis et que si vous ne l'avez pas déjà implémenté, c'est que vous avez vos raisons (c'est pas vraiment une fonctionnalité demandées par vos utilisateurs payant par exemple).
Mais pour ma part j'ai trouvé un moyen de contournement, donc pour l'instant ça va.
Merci pour votre réponse.
[^] # Re: réponses sur les réserves
Posté par SaintGermain . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 2.
Non je suis presque sûr que même sans cette histoire de cache, les accès via les applis mobiles ne sont pas enregistrées:
https://github.com/Piwigo/Piwigo-Mobile/issues/257
Apparemment c'est une histoire d'API.
[^] # Re: Piwigo et Cialis
Posté par SaintGermain . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 2.
Effectivement cela me semble un gros trou de sécurité et trouver la faille ne semble pas si facile…
Cela ne va pas atténuer mon préjugé sur la sécurité des applis en PHP… et je vais continuer à mettre mon Piwigo derrière un HTTP Basic Access Authentication.
Sinon je viens de tester une nouvelle fois et si on connaît le nom de l'album et le nom du fichier d'une photo, n'importe qui peut toujours accéder à la photo, sans avoir besoin de se connecter.
C'était un problème remonté en 2012:
https://piwigo.org/forum/viewtopic.php?id=20372&p=1
Donc Piwigo c'est bien mais faites très attention à la sécurité et à la confidentialité…
[^] # Re: Photos chez google
Posté par SaintGermain . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 3. Dernière modification le 05 octobre 2018 à 23:17.
Sa question est pertinente, car tout le monde ne respecte pas le robots.txt.
Pour ma part, j'ai ajouté une couche d'HTTP Basic Access Authentication pour empêcher ce genre d'accès.
Du coup dans mon email, je n'ai que le lien unique (les identifiants ayant été envoyé avec un email précédent).
Ce n'est pas l'idéal, mais cela permet de se protéger contre le scan et accès automatique.
[^] # Re: réponses sur les réserves
Posté par SaintGermain . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 3.
URL semi-privée, c'est lié au fait que ce n'est pas très sécurisé. Comme cité plus bas, si tes emails sont scannés (genre si ton correspondant est sur mail.ru ou autre), tes photos se retrouvent indexées.
Seafile par exemple contourne un peu le problème en proposant aussi de protéger avec un mot de passe.
Donc il ne suffit pas d'avoir le lien, il faut aussi le mot de passe.
Oui c'est ce que j'utilise. J'avais aussi essayé avec un utilisateur générique mais cela n'avait jamais bien fonctionné sans que je sache bien pourquoi (je n'ai pas réussi à déboguer et cela semble marcher pour les autres). Le problème que je rencontre c'est qu'il faut que j'envoie un faux email pour récupérer le lien car je souhaite envoyer moi-même le lien.
C'est intéressant, le plugin doit être nouveau car je ne l'avais pas repéré il y 2 ans quand je me suis intéressé à la question. Merci pour l'astuce !
Sans vouloir trop m'étendre, il y a plusieurs raisons pour laquelle j'ai rajouté une couche d'HTTP Basic Access Authentication :
- Il me semble que le niveau de sécurité/confidentialité de Piwigo a un soucis (https://piwigo.org/forum/viewtopic.php?id=20372&p=3). Du coup j'avais essayé de configurer pour empêcher l'accès aux photos sans être connecté (https://github.com/yonjah/piwigo_privacy) mais cela n'avait pas fonctionné. De guerre lasse, j'ai utilisé l'HTTP Basic Access Authentication.
- J'ai moyennement confiance dans la sécurité des applications PHP (oui c'est un préjugé et j'y travaille)
- Je n'ai pas beaucoup de temps pour la maintenance de mon système, et je suis Piwigo seulement de temps en temps. Donc je ne suis pas très réactif quand une nouvelle version de Piwigo est disponible pour l'installer (par contre j'ai activé l'installation automatique des mises à jour de sécurité sur ma distribution).
Bref le HTTP Basic Access Authentication c'est le garde-fou du pauvre.
J'avoue que je suis très vieille école sur le problème de la synchronisation et je suis très attaché à rsync. Cela permet de configurer à volonté la synchronisation. J'ai par exemple établie des règles pour ne pas synchroniser certaines photos. Et si je dois interrompre la synchronisation ou la reprendre, j'ai 100% confiance en rsync de bien optimiser la reprise et de ne pas corrompre de fichiers. Je doute malheureusement que Piwigo Remote Sync soit aussi flexible.
L'appli officielle iOS est top. L'appli Piwigoclient sous Android est aussi très bien et l'auteur très sympa. Ce serait dommage de lui causer des soucis à cause du nom. À noter qu'il a intégré le mode optionnel Masonry layout qui permet d'optimiser l'affichage des photos de manières élégantes (et pas dispo sous iOS).
J'en profite pour poser la question de savoir pourquoi les accès via les applis mobiles ne sont pas enregistrés dans l'historique de Piwigo ? C'est bien dommage…
En tout cas ton intervention ne fait que renforcer mon impression que l'équipe Piwigo est vraiment dynamique et sympathique !
Merci pour ce magnifique boulot.
[^] # Re: Salut à Toi
Posté par SaintGermain . En réponse au journal Partager ses photos et auto-hébergement. Évalué à 4.
Il faudrait faire un journal sur le sujet !
Partager simplement ses photos et vidéos, c'est un besoin très courant, donc si tu as réussi à monter quelque chose qui soit simple et agréable à utiliser, cela devrait intéresser les utilisateurs.
Depuis que j'utilise Piwigo, je dois cependant noter que c'est loin d'être si facile.
Entre les problèmes de navigateur ou système d'exploitation, avoir quelque chose de responsive mais qui optimise bien l'espace, avoir des apps disponibles sur iOS/Android, etc.
C'est quand même beaucoup de boulot !