Lut.im, un service d'hébergement d'images gratuit, libre et anonyme

Posté par  (site web personnel) . Édité par Benoît Sibaud, Florent Zara et palm123. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
60
17
fév.
2014
Internet

Que celui qui n'a jamais voulu partager simplement une capture d'écran lève le doigt. Personne ? Le partage d'images nous confronte souvent à divers problèmes :

  • un courriel prend du temps (retrouver l'adresse du destinataire, l'envoi, etc.) ;
  • un courriel prend de la place. Ce n'est pas grand chose, mais pour une image jetable, c'est de l'espace disque perdu, que ce soit dans le dossier "Envoyé" de l'expéditeur ou celui du destinataire. Oui, on peut supprimer le mail, mais c'est encore une action à effectuer.
  • une solution commme imgur nous ramène au sempiternel problème des Conditions Générales d'Utilisation imbuvables, non traduites et que l'on ne lit de toute façon jamais en entier. Pour ce genre de service, on risque de fournir certains droits à l'hébergeur… et ça c'est pas cool !
  • un ownCloud (ou équivalent) fera bien le travail, au prix d'une certaine complexité de partage et de liens à la longueur ahurissante.

Logo de LUTIm

Pour répondre à cette problématique, j'ai codé LUTIm (prononcez comme lutin). Écrit en Perl avec le framework Mojolicious, utilisant le Twitter Bootstrap, un sous ensemble de Font Awesome et un plugin jQuery légèrement modifié pour la gestion du glisser/déposer, LUTIm est un logiciel libre (licence AGPL) de partage d'image anonyme et gratuit.

NdM : N'oublions pas nos amis de Toile Libre qui proposent un service d'hébergement d'image qui s'en rapproche : Pix 1.1.

Le principe est simple : on glisse/dépose des images (ou via le sélecteur de fichier classique) et on récupère 3 liens (courts) :

  • un lien vers l'image (utilisable dans une balise img par exemple) ;
  • un lien de téléchargement de l'image (pour éviter le clic droit > Enregistrer sous) ;
  • un lien vers une page qui affiche l'image et qui est utilisable sur Twitter (l'image apparaîtra dans le tweet).

Capture d'écran de l'interface de LUTIm

Des options du formulaire d'envoi permettent de supprimer automatiquement les images après la première consultation ou après 24h.

Les adresses IP des envoyeurs d'image et celles des consulteurs sont enregistrées dans les logs, mais c'est quelque chose de tout à fait habituel sur tout site web (ces IP ne sont plus conservées, cf commits 1 et 2). Les adresses IP des envoyeurs ainsi que celle du dernier consulteur sont enregistrées dans la base SQLite pour accélérer la recherche d'informations en cas de requête judiciaire (je sais comme il peut être fastidieux et long de chercher dans des logs). Lors de la suppression automatique d'une image, le fichier est bel et bien supprimé, mais son entrée en base de données persiste et contient l'empreinte SHA512 du fichier.

De par sa nature libre, vous pouvez bien évidemment installer et utiliser très facilement LUTIm sur votre propre serveur, mais vous pouvez aussi vous contenter d'utiliser l'instance officielle de LUTim. LUTIm est disponible en français et en anglais, la langue étant choisie selon les préférences du navigateur. Toutes les bonnes volontés sont les bienvenues pour proposer d'autres langues ! Enfin, LUTIm propose un plugin pour Shutter, logiciel de capture d'écran, pour permettre à celui-ci d'envoyer les captures sur http://lut.im directement (plugin à installer soi-même, le site du projet ayant l'air cassé, je n'ai pu leur remonter le plugin).

Et pour finir, un lien vers une nimage pour tester (source).

Aller plus loin

  • # LUTIm évolue déjà

    Posté par  (site web personnel) . Évalué à 6.

    Les options de suppression automatique ont été améliorées : pas de suppression, suppression au bout d'un jour, d'une semaine, d'un mois ou d'un an

    Capture d'écran de LUTIm amélioré

    La mise à jour est tout ce qu'il y a de plus simple grâce à Mojolicious et son super serveur intégré, hypnotoad

    git pull
    carton exec hypnotoad script/lutim
    

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

    • [^] # Re: LUTIm évolue déjà

      Posté par  (site web personnel) . Évalué à 3.

      carton exec hypnotoad script/lutim

      C'est un serveur en carton ? :-P

      • [^] # Re: LUTIm évolue déjà

        Posté par  (site web personnel) . Évalué à 2.

        En carton, peut-être, mais j'ai eu droit à un billet de Korben, j'ai vu les requètes augmenter mais le serveur n'a pas bronché :) Un vrai bonheur Mojolicious ! (et son serveur web intégré, hypnotoad)

        :-)

        Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Fap machine.

    Posté par  . Évalué à -10.

    Ayant lu le titre, j'ai tout de suite traduit par « FAP MACHINE ». :)

  • # questions légales

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 17 février 2014 à 11:50.

    Bien évidemment, pour des questions légales, il n'est pas possible d'avoir un service totalement anonyme : les adresses IP des envoyeurs d'image et celles des consulteurs sont enregistrées dans les logs,

    Je savais pour les envoyeurs d'images (obligation de pouvoir remonter à l'auteur, le "créateur de contenu"), mais je ne savais pas pour les consulteurs (à ma connaissance, seuls les FAI ont une obligation pour les gens qui ne créent rien).

    Quel est le texte de loi qui oblige à conserver les logs des visiteurs, pour les admins de site web?

    mais c'est quelque chose de tout à fait habituel sur tout site web.

    Oui, mais pas forcément pour des questions légales, mais pour du debug, des stats etc…

    PS : ça peut troller sec avec la nimage "choquante" (pour certains)… :)

    • [^] # Re: questions légales

      Posté par  (Mastodon) . Évalué à 3.

      PS : ça peut troller sec avec la nimage "choquante" (pour certains)… :)

      Tu en veux, du choquant ? C'est la Dirty Valentine !

    • [^] # Re: questions légales

      Posté par  . Évalué à 2.

      Une solution pour davantage de confidentialité serait -comme le fait 0bin- de stocker les images avec une clef symétrique figurant dans l'url après # (256 bits, pas 48, par contre).

      • [^] # Re: questions légales

        Posté par  . Évalué à -4.

        Ça change quoi ? Je veux dire là tu as une clef qui est visible de tous (y compris les routeurs, même si tu passe par du HTTPS) et le chiffrement déchiffrement se fait coté serveur. Donc tu cache l'image à qui au final ? Si c'est juste pour avoir des url pas facile à retrouver autant utiliser un algo de hashage correct, non ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: questions légales

          Posté par  (site web personnel) . Évalué à 1.

          Si tu parles de la requête pour récupérer la ressource, je ne crois pas que ce qui suit le # soit envoyé au serveur, justement.

          Après, cette information là a bien du transiter par mail ou autre, à un moment…

        • [^] # Re: questions légales

          Posté par  . Évalué à 2.

          Ah non, la clef doit rester dans le navigateur du client, et être transmise par un tiers canal à d'autres clients.

        • [^] # Re: questions légales

          Posté par  (site web personnel) . Évalué à 10.

          Inquiétant qu'un message qui fait deux grosses erreurs (en HTTPS l'URL est chiffrée, et le hash d'une URL ne part pas au serveur) soit voté pertinent…

          • [^] # Re: questions légales

            Posté par  . Évalué à 2.

            En effet j'ai vérifié seulement après coup malheureusement…

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: questions légales

            Posté par  (site web personnel) . Évalué à 0.

            Bien qu'il ait tort, je trouve la remarque pertinente justement parce qu'on oublie souvent que l'ancre n'est pas envoyé au serveur (mais toutefois exploitable en JS…).

            alf.life

        • [^] # Re: questions légales

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          Ce ne sont pas juste des URL pas facile à trouver. Parmi les avantages :

          • Protection de la vie privée des utilisateurs. Les admins ne sont pas capable de déchiffrer ce qui est stocké
          • Si le serveur est saisi, les données sont chiffrées
          • Interdit tout filtrage ou censure pro-active des administrateurs
          • Sur injonction légale, les admins peuvent supprimer un contenu illégal, mais n'ont aucun moyen de savoir s'il a été remis en ligne.*

          Pour plus d'informations, voir la dépêche sur LinuxFr.org au sujet de ZeroBin

        • [^] # Re: questions légales

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Visible par les routeurs ? Mais non, pas du tout, si on utilise HTTPS.

    • [^] # Re: questions légales

      Posté par  (site web personnel) . Évalué à 1.

      Certes, les IP des visiteurs ne sont peut-être pas une obligation légale, mais dans le doute, je les logue. Et ça peut aussi me servir pour des stats.

      Si quelqu'un a un lien kivabien pour tout ce qui est responsabilités et obligations légales d'un hébergeur, je suis preneur.

      Pour le troll de l'image, bah bof. Je vois rien de choquant, à part éventuellement un brin de nudité, et encore, moins que l'origine du monde, alors zut :-)

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: questions légales

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        Les enregistrer dans le doute me parait très dangereux, cela peut vous faire passer dans la catégorie « stocke des données personnelles » (et doit donc faire des formalités à la CNIL).

        Et, pendant qu'on en est au flicage, il faudrait aussi stocker le numéro de port :-) http://www.bortzmeyer.org/6302.html

        • [^] # Re: questions légales

          Posté par  (site web personnel) . Évalué à 1.

          Merci :-)

          Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

          • [^] # Re: questions légales

            Posté par  (site web personnel) . Évalué à 5.

            Pour la CNIL, je suis dispensé :

            « La dispense n°6 concerne les sites web ou blogs mis en œuvre par des particuliers à titre privé qui peuvent permettre, d’une part, la collecte de données à caractère personnel de personnes qui s’y connectent et, d’autre part, la diffusion de données à caractère personnel (nom, images de personnes ou tout autre élément permettant d’identifier une personne physique). La diffusion et la collecte de données à caractère personnel opérées à partir d’un site web dans le cadre d’activités professionnelles, politiques, ou associatives restent soumises à une déclaration préalable auprès de la CNIL. »

            http://www.cnil.fr/vos-obligations/declarer-a-la-cnil/dispense/mon-secteur-dactivite/mon-theme/mon-fichier/dec-mode/DISPLAYLISTFICHE/?tx_oxcscnildeclaration_pi1[sauid]=7

            C'est moi qui ai mis en gras.

            Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

            • [^] # Re: questions légales

              Posté par  . Évalué à 7.

              sites web ou blogs mis en œuvre par des particuliers à titre privé

              mais est-ce encore «privé» si tu offres un service à des tiers ?

              • [^] # Re: questions légales

                Posté par  (site web personnel) . Évalué à 5.

                « La diffusion et la collecte de données à caractère personnel opérées à partir d’un site web dans le cadre d’**activités professionnelles, politiques, ou associatives** restent soumises à une déclaration préalable auprès de la CNIL. »

                Je ne rentre dans aucune des catégories indiquées, je ne gagne quasi-rien (flattr et bitcoin, pour l'instant j'ai eu 2 flattr) donc pas d'activité commerciale… C'est un site web perso, ouvert à tous ok, mais tout comme mon blog offre des infos à tout un chacun. Pour moi je suis clean, mais c'est une bonne question.

                Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: questions légales

        Posté par  (site web personnel) . Évalué à 4.

        Certes, les IP des visiteurs ne sont peut-être pas une obligation légale, mais dans le doute, je les logue.

        Ce n'est pas moi qui ai écrit "pour des questions légales, il n'est pas possible (…)" sur l'adresse IP des visiteurs, donc je m'attendais que si quelqu'un me parle d'obligation légales, il sache plus que "dans le doute".

        il faudrait corriger la dépèche genre "on ne sait pas, on s'en fout un peu de l'anonymat en fait, dans le doute on logge sans se renseigner si c'est obligatoire ou si on peut éviter" voire ne rien mettre, la ça fait penser que les logs sont au minimum par rapport au légal alors que personne ne le sait.

        Et ça peut aussi me servir pour des stats.

        Oui, mais la d'un coup ça fait moins "vendeur" que ce qu'il y a dans la dépèche ;-)

        Pour le troll de l'image, bah bof. Je vois rien de choquant,

        Je te rassure, moi non plus, juste que j'imagine des hauts le coeur chez certains.

        • [^] # Re: questions légales

          Posté par  . Évalué à 3.

          Certes, les IP des visiteurs ne sont peut-être pas une obligation légale, mais dans le doute, je les logue.

          il faudrait corriger la dépèche genre "on ne sait pas, on s'en fout un peu de l'anonymat en fait, dans le doute on logge sans se renseigner si c'est obligatoire ou si on peut éviter" voire ne rien mettre, la ça fait penser que les logs sont au minimum par rapport au légal alors que personne ne le sait.

          Bien d'accord avec Zenitram. L'anonymat est quelque chose de sérieux, surtout sur internet, on se place dans le camp de ceux qui fliquent ou dans ceux qui le refusent (et dans ce dernier camp, il y a ceux qui le refusent mais qui y sont obligés par les lois liberticides de cette triste époque).

          Donc tu fais semblant d'être dans la dernière catégorie alors que de fait tu es dans la première. Libre à toi, bien sûr, mais comme le souligne Zenitram, aie la franchise de le dire.

          Ça n'est pas pour rien que duckduckgo et ixquick se taillent un franc succès dans les [meta]moteurs de recherche juste sur le fait qu'ils ne tracent pas l'IP du visiteur.

          • [^] # Re: questions légales

            Posté par  (site web personnel) . Évalué à 2.

            Donc tu fais semblant

            Certes, mais de bonne foi. On va plutôt dire que je me suis trompé. Et accessoirement, j'ai bien précisé dans les informations ce que je loguais. Je ne dissimule pas, tu l'admettras.

            Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

            • [^] # Re: questions légales

              Posté par  . Évalué à 2.

              Je ne dissimule pas, tu l'admettras.

              Oui, bien sûr, mais moi je serais parti de l'hypothèse inverse : "j'aimerais bien ne pas fliquer si la loi ne m'y oblige pas, donc voyons ce que disent les textes et si je peux m'en sortir sans loguer l'IP".

              D'autant plus que, contrairement à ddg, tu héberges du contenu et qu'il est fort possible que tu sois légalement tenu de fournir la source d'une image que les censeurs désapprouvent (ça me rappelle le beau film Cinema Paradisio et la séquence où sont visionnés tous les rushes censurés par le curé).

              Ceci dit ton site est génial, d'une simplicité exemplaire, et le fait de pouvoir déployer le logiciel sur son propre serveur est un très gros plus.

        • [^] # Re: questions légales

          Posté par  (site web personnel) . Évalué à 4.

          Reformulé dans la dépêche.

          • [^] # Re: questions légales

            Posté par  (site web personnel) . Évalué à 3.

            Pourrais-tu updater la dépèche encore une fois ? J'ai modifié Lutim pour anonymiser les logs et j'ai updaté les informations.

            Maintenant, seule l'IP de l'envoyeur est enregistrée. :-)

            Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Une proposition d'amélioration

    Posté par  . Évalué à 1.

    C'est vraiment pas mal, mais il y a un détail un peu bête qui me gène. Pourquoi la zone où est écrit "déposer vos images ici" n'affichage pas d'aperçu du copier-coller? Du coup, c'est déconcertant lorsque l'on utilise ton service…

    • [^] # Re: Une proposition d'amélioration

      Posté par  (site web personnel) . Évalué à 4.

      Maintenant il y a une barre de progression (c'est déjà mieux), et peut-être, si ce n'amène pas trop de dépendances, y aura-t'il dans le futur une miniature de l'image dans le message qui donne l'URL.

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Re: Internet— Lut.im, un service d'hébergementd'images gratuit, libre et anonyme

    Posté par  (site web personnel) . Évalué à 1.

    Dans le cadre de capture d'ecran anonyme, ça pourrait etre bien de pouvoir flouter certaines zones.

  • # Limitation à des images

    Posté par  (site web personnel) . Évalué à 8.

    Pourquoi limiter aux images ?

    Ce genre d'outil pourrait aussi être utile pour envoyer à plusieurs personnes un fichier quelconque qu'on ne veut pas (ou ne peut pas) faire passer en pièce jointe.

    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: Limitation à des images

      Posté par  (site web personnel) . Évalué à 10.

      Ça c'est la suite : Lufi (Let's Upload That File) sera fait pour ça et sera un projet Framasoft. Et il utilisera un système de chiffrement comme 0bin.

      Pourquoi je ne l'ai pas fait dès le départ ? Parce que je prends déjà certainement des risques en hébergeant des images potentiellement pédopornos et que je n'ai pas les épaules assez larges (et mon serveur non plus) pour faire un service d'hébergement de fichiers.

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Source de la nimage pour tester

    Posté par  . Évalué à 5.

    Même si son pseudo apparaît sur l'image, ça me semble plus correct de mettre aussi l'adresse de son blog :
    http://www.bloglaurel.com/

  • # Curieux la base de donnée

    Posté par  . Évalué à 4.

    J'ai un peu de mal avec ça

    Les adresses IP des envoyeurs ainsi que celle du dernier consulteur sont enregistrées dans la base SQLite pour accélérer la recherche d'informations en cas de requête judiciaire (je sais comme il peut être fastidieux et long de chercher dans des logs).

    Que tu sois obligé d'avoir des logs, je le conçois parfaitement, néanmoins j'ai du mal à comprendre l'intérêt de la base de donnée pour l'usage que tu mentionnes. Si requête judiciaire il doit y avoir, tu donnes les logs, ou une image du serveur suivant ce que l'on te demande. Ce n'est, à mon avis, pas ton rôle de faire un quelconque tri dans les infos que l'on te demande.

    • [^] # Re: Curieux la base de donnée

      Posté par  (site web personnel) . Évalué à 1.

      Je suis amené dans mon boulot à faire des recherches dans les logs.

      Bah c'est TRÈS chiant. Je ne sais pas si c'est moi qui devrait faire la recherche en cas de problème (je le pense puisque je le fais au boulot et qu'on ne file pas les logs à qui que ce soit) mais au cas où je dois me taper une identification, ça ira plus vite comme ça.

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: Curieux la base de donnée

        Posté par  . Évalué à 3.

        grep   174.17.41.31:34577   /var/log/lutim/*.log

        Perso, j'aime bien :-)

        • [^] # Re: Curieux la base de donnée

          Posté par  (site web personnel) . Évalué à 4.

          Pas quand j'aurai un an de logs et toujours un serveur asthmatique (un kimsufi2G, atom simple thread d'il y a 2 ans) et qui fait tourner 7 containers lxc.

          Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

          • [^] # Re: Curieux la base de donnée

            Posté par  . Évalué à -1.

            Si tu as beaucoup de données par rapport à la puissance de ta babasse, en quoi un SGBD va aider ? Ça nécessite plus de mémoire qu'un journal texte, donc forcément moins bon pour ton problème.

            Si un SGBD te donnes de meilleurs résultats, c'est que tu ne stocke moins de choses dans ta base de données que dans ton journal.
            Il ne te reste plus qu'à stocker moins de chose dans le journal :-)

            • [^] # Re: Curieux la base de donnée

              Posté par  (site web personnel) . Évalué à 3.

              Si tu as beaucoup de données par rapport à la puissance de ta babasse, en quoi un SGBD va aider ? Ça nécessite plus de mémoire qu'un journal texte, donc forcément moins bon pour ton problème.

              Bah un grep sur des gros logs va prendre du temps. Un select kivabien et j'aurais ma réponse. Pis de toute façon, la bdd (sqlite) est déjà là pour le fonctionnement du service : c'est pas un champ en plus qui va bouffer beaucoup de ressources en plus.

              Si un SGBD te donnes de meilleurs résultats, c'est que tu ne stocke moins de choses dans ta base de données que dans ton journal.
              Il ne te reste plus qu'à stocker moins de chose dans le journal :-)

              Et comment je fais mes stats moi ? :p

              Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

            • [^] # Re: Curieux la base de donnée

              Posté par  (site web personnel) . Évalué à 4.

              Posté par Kerro

              Ouais, bah j'arrêterai de lire tes avis, hein. Jusqu'à présent je leur prêtais un certain crédit parce que, moi, l'adminsys, c'est pas mon métier, mais prétendre que "grep toto -r /var/log/*" est plus efficace qu'une BDD ou qu'un quelconque outil d'indexation encore plus spécialisé… ça fait peur. Pour ton employeur.

              • [^] # Re: Curieux la base de donnée

                Posté par  (site web personnel) . Évalué à 3.

                l'adminsys, c'est pas mon métier

                tout est dit :-)

                Publier un service sur Internet, c'est gérer la montée en charge, ce ne sont pas 2-3 évaluations sur un environnement de développement (ou une production non surchargée) qui permettront de choisir la meilleure conception en développement pour que tout se passe bien en production ultérieurement.

                Utiliser une base de données en écriture, c'est générer des locks qui pénaliseront inévitablement les select à titre de statistiques (alors que ces derniers pourraient être fait en asynchrone, sur une "base" de la veille par exemple). Si les logs sont bien formatés, rien n'empêche de déporter les imports dans une base décorrélée du service principal (consulter des images, en soumettre) pour l'exploiter à des fins de statistiques.

                Combien de sites subissant l'effet /. (se faisant linuxfriser en bon françois) ont dû désactiver piwigo qui utilise le même genre de conception ?

                Par ailleurs, utiliser une base sqllite compliquera le fonctionnement concernant les accès concurrents en écriture s'il y a plusieurs serveurs web (avec une seule base centralisée, devenant le SPOF par nature et du fait de la conception).

                Ne t'en déplaise, contrairement à toi, je continuerai à pertinenter Kerro< pour ses avis, demandant parfois d'être approfondis ou explicités, il est vrai, mais pointant un vrai sujet la plupart du temps (bon, parfois il peut raconter de mauvaises vannes, comme tout le monde :D).

                En outre, un tail -t /var/log/production.log | grep xxxxxx permettra de surveiller ce qui se passe en direct, en cas de surcharge, sans avoir à désactiver les statistiques… Il pourra même y en avoir plusieurs en parallèle (chacun ne traitant que la sortie courante), plutôt que plusieurs select en parallèle, bloqués par les écritures en base et nécessitant d'avoir les index chargés en mémoire pour être efficaces…

                • [^] # Re: Curieux la base de donnée

                  Posté par  (site web personnel) . Évalué à 4.

                  Combien de sites subissant l'effet /. (se faisant linuxfriser en bon françois) ont dû désactiver piwigo qui utilise le même genre de conception ?

                  Tu veux parler de Piwik peut-être :p Parce que bon, Piwigo, c'est une galerie de photo…

                  Par ailleurs, utiliser une base sqllite compliquera le fonctionnement concernant les accès concurrents en écriture s'il y a plusieurs serveurs web (avec une seule base centralisée, devenant le SPOF par nature et du fait de la conception).

                  J'suis pas fou, je sais bien que sqlite (avec un seul « l ») n'est pas fait pour ça. Mais bon, je vois plutôt l'avenir de Lutim comme les framapads : plusieurs instances, qu'on fait tourner quand la bdd devient trop grosse (bah oui, y a jamais rien de supprimé, au bout d'un moment, ça se ressent sur les perfs des pads, surtout avec mysql).

                  En outre, un tail -t /var/log/production.log | grep xxxxxx

                  multitail -e xxxxxx /var/log/production.log jeune padawan. Ton tail-grep, c'est tellement 2013 !

                  Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

                • [^] # Re: Curieux la base de donnée

                  Posté par  (site web personnel) . Évalué à 1.

                  Utiliser une base de données en écriture, c'est générer des locks qui pénaliseront inévitablement les select à titre de statistiques (alors que ces derniers pourraient être fait en asynchrone, sur une "base" de la veille par exemple). Si les logs sont bien formatés, rien n'empêche de déporter les imports dans une base décorrélée du service principal (consulter des images, en soumettre) pour l'exploiter à des fins de statistiques.

                  Combien de sites subissant l'effet /. (se faisant linuxfriser en bon françois) ont dû désactiver piwigo qui utilise le même genre de conception ?

                  Par ailleurs, utiliser une base sqllite compliquera le fonctionnement concernant les accès concurrents en écriture s'il y a plusieurs serveurs web (avec une seule base centralisée, devenant le SPOF par nature et du fait de la conception).

                  Ouais bah si t'as une unique instance de BDD t'es un adminsys un peu gland, hein. Réplication master/slave pour éviter le SPOF et tu peux en bonus faire tes requêtes en lecture sur le slave.

                  • [^] # Re: Curieux la base de donnée

                    Posté par  (site web personnel) . Évalué à 2.

                    N'étant pas adminsys, je ne me sens pas visé par ton insulte :-)

                    Cela ne résout pas le point que sous forte charge, mobiliser une base en écriture à des fins de statistiques, pour répondre à chaque requête HTTP est sous-optimal :

                    • tu ne réponds pas pour la linuxfrisation ? (ou tout simplement un spammeur en masse).
                    • sqlite ne gère pas les écritures concurrentes, chaque serveur web s'il y en a plusieurs attendra que le précédent ait travaillé, pas de parallélisation… dommage :/

                    Sinon oui, le master-slave est effectivement une possibilité pour les select et d'ailleurs, même si je ne croyais pas, il y a de la réplication pour sqlite :

                    Comme quoi faire une remarque permet de trouver de nouvelles choses :-)

                  • [^] # Re: Curieux la base de donnée

                    Posté par  (site web personnel) . Évalué à 5.

                    Merci pour le gland.

                    À part ça, peut-être qu'avant de se faire chier avec de la réplication, faut peut-être voir si j'en ai besoin. Pour l'instant, non, quand je verrais la fréquentation augmenter ou les performances tomber, je me pencherai dessus.

                    À chaque besoin sa solution, là j'ai pas de gros besoins.

                    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

          • [^] # Re: Curieux la base de donnée

            Posté par  . Évalué à 1.

            Pourquoi faire le grep sur le serveur même ? Autant récupérer les fichiers logs et grepper sur ton poste.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Curieux la base de donnée

              Posté par  (site web personnel) . Évalué à 7.

              Ce qui veut dire télécharger les logs… juste beaucoup plus long qu'un select dans une bdd.

              C'est quoi le problème avec le select ? J'ai une base de données ultra light, un champ en plus ne va pas la tuer ni la faire grandir des masses et ça me permet d'aller 1000 fois plus vite que tout ce que vous pouvez proposer avec grep. Ok, c'est pas le genre de truc à généraliser partout, loin de là, mais dans mon cas, y a aucun problème.

              Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

              • [^] # Re: Curieux la base de donnée

                Posté par  . Évalué à 5.

                C'est quoi le problème avec le select ?

                Tu indiques que tu es court en ressources. On comprends entre les lignes que tes accès diques sont dégueux. Donc forcément ça fait tiquer lorsque tu annonces que tu utilises un SGBD : ça consomme de la mémoire, et question accès disque ça doit bien être au moins 5 fois pire qu'un fichier à plat (sauf si tu n'as pas d'index, mais dans ce cas la base de données ne peut rien « accélérer ».

                Ensuite on comprends que tu utilises sqlite. Ah ok, déjà c'est moins consommateur en mémoire que les « gros » SGBD. Mais les accès disque sont toujours bien plus nombreux.

                En enfin tu expliques que ta base de données est hyper légère. C'est là qu'on ne pige plus. Il y a un élément qui nous échappe, car si tu as peu de données à stocker, rien ne battra un fichier à plat lors des écritures. Et lors de la lecture

                Lors des milliers d'écritures quotidiennes, ça consomme quel dalle. Lors des quelques lectures hebdomadaires, un con de journal de 10 Mo prends moins d'une seconde à passer au grep (je viens de tester sur un Pentium III avec 128 Mo de mémoire et un vieux disque-dur. Fichier non présent dans le cache).
                Donc voilà, y'a un truc qui nous échappe :-)
                Ceci dit, ce n'est (peut-être) pas un sujet ultra important.

                • [^] # Re: Curieux la base de donnée

                  Posté par  (site web personnel) . Évalué à 3.

                  En enfin tu expliques que ta base de données est hyper légère. C'est là qu'on ne pige plus. Il y a un élément qui nous échappe, car si tu as peu de données à stocker, rien ne battra un fichier à plat lors des écritures. Et lors de la lecture

                  Bah, déjà pour développer, c'est quand même plus simple d'avoir une bdd que d'analyser un fichier texte. Et il y a un index : l'adresse de l'image. C'est quand même plus efficace que de grepper dans le fichier pour renvoyer l'image.

                  Par ailleurs :
                  ```
                  time grep --color xxxxxxxx log/production.log
                  0.00s user 0.01s system 35% cpu 0.022 total

                  time sqlite3 lutim.db "select * from lutim where short = 'xxxxxxx'"
                  0.00s user 0.00s system 40% cpu 0.010 total
                  ```

                  Voilà : j'ai 2.6Mio de log et une requête en bdd va plus vite (2654 fichiers enregistrés jusque là). Certes, pour plus de cpu, mais quand je devrais chercher dans de plus gros logs, je pense que le rapport de cpu s'inversera.
                  Et oui, entre 0.010 et 0.022 secondes, on s'en fout un peu de qui est le plus rapide, mais ça ne fait même pas une semaine que lut.im est en ligne, donc y a pas encore beaucoup de logs. Quand on me demandera de chercher dans un an de logs, je sais lequel sera le plus rapide.

                  Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

                  • [^] # Re: Curieux la base de donnée

                    Posté par  . Évalué à 2.

                    c'est quand même plus simple d'avoir une bdd que d'analyser un fichier texte

                    Ça c'est affaire de goût. Je trouve le SQL bien plus verbeux qu'une expression régulière, sans compter les shells en général pourris (sqlite est mieux que sqlplus mais ça reste largement moins agréable qu'un bon vieux bash).

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Curieux la base de donnée

                    Posté par  (site web personnel) . Évalué à 2.

                    Bah, déjà pour développer, c'est quand même plus simple d'avoir une bdd que d'analyser un fichier texte. Et il y a un index : l'adresse de l'image. C'est quand même plus efficace que de grepper dans le fichier pour renvoyer l'image.

                    Pour la montée en charge, ce qui compte, c'est de limiter le coût des opérations effectuées le plus souvent.

                    En l’occurrence, il y aura beaucoup plus d'écritures de logs que de lectures. Et en plus, ces lectures pourraient être déportées sur un autre machine.

                    Donc ce n'est pas le coût de la recherche que tu devrais comparer, mais plutôt le coût d'écriture d'une entrée du log. Et là, pas besoin de faire de benchmark: SQLite sera toujours plus lent que d'écrire une centaine d'octets à la fin d'un fichier.

                    Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt

                    • [^] # Re: Curieux la base de donnée

                      Posté par  (site web personnel) . Évalué à 5.

                      Donc ce n'est pas le coût de la recherche que tu devrais comparer, mais plutôt le coût d'écriture d'une entrée du log. Et là, pas besoin de faire de benchmark: SQLite sera toujours plus lent que d'écrire une centaine d'octets à la fin d'un fichier.

                      Moui, mais quelle est la différence entre créer une entrée en bdd (ce que je suis bien obligé de faire de toute façon, on est bien d'accord ?) et créer une entrée en bdd avec un champ en plus ? Si je faisais des appels distincts à la bdd pour faire mes "logs", je suis d'accord que ce serait coûteux, mais pas dans ce cas.

                      Car je le redis : mettre l'IP de l'envoyeur en bdd se fait à la création des infos de l'image dans la bdd. Pour moi le surcoût est nul. Et c'est la seule IP que j'enregistre désormais.

                      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

                      • [^] # Re: Curieux la base de donnée

                        Posté par  . Évalué à 2.

                        quelle est la différence entre créer une entrée en bdd (ce que je suis bien obligé de faire de toute façon, on est bien d'accord ?) et créer une entrée en bdd avec un champ en plus ?

                        Voilà le truc qui m'échappait et qui fait sens à ta manière de procéder.
                        Ton champs supplémentaire est indexé (sinon c'est pire qu'avec un grep), donc l'opération n'est pas aussi gratuite que ça.

                        • [^] # Re: Curieux la base de donnée

                          Posté par  (site web personnel) . Évalué à 2.

                          Non, l'ip n'est pas indexée car je recevrai plus sûrement des demandes "qui a uploadé tel image ?" plutôt que "quelles sont les images uploadées par l'ip truc ?".

                          Donc l'index servant à fournir les images suffira. Pis si c'est pas le cas, ce sera moins long de télécharger la base sqlite sur une machine qui poutre plutôt que les logs.

                          Mais puisque ça fait tant débat, je remettrai l'IP dans les logs, moi j'utiliserai la bdd et tout le monde sera content. :-)

                          Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

                          • [^] # Re: Curieux la base de donnée

                            Posté par  . Évalué à 2.

                            Ça ne fait pas débat, c'est toi le développeur… mais nous sommes sur Linuxfr hein :-)

                            .

                            l'ip n'est pas indexée car je recevrai plus sûrement des demandes "qui a uploadé tel image ?" plutôt que "quelles sont les images uploadées par l'ip truc ?".

                            Pas bête, effectivement.

                            .

                            ce sera moins long de télécharger la base sqlite sur une machine qui poutre plutôt que les logs.

                            Si tu stockes la même chose dans sqlite que dans un journal, alors le journal est probablement de taille équivalente. Il ne contient pas d'index ni de structure de données, ni de pré-réservation d'espace. Mais les dates, adresses et nombres prennent plus de place.
                            J'insiste sur : si tu stockes la même chose.

                            • [^] # Re: Curieux la base de donnée

                              Posté par  (site web personnel) . Évalué à 2.

                              si tu stockes la même chose

                              Bah non, justement pas. J'écris dans le journal une ligne (anonyme) dès que:
                              * qq'un va sur la page d'accueil
                              * pousse une image
                              * regarde une image
                              * une image expire

                              Tout ça pour éventuellement faire des stats.

                              Ceci dit, j'ai codé un truc qui tourne en cron et qui file qq stats : http://lut.im/stats On voit bien l'effet Korben :)

                              Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

                              • [^] # Re: Curieux la base de donnée

                                Posté par  . Évalué à 0.

                                Ceci dit, j'ai codé un truc qui tourne en cron et qui file qq stats : http://lut.im/stats

                                Il n'y a pas d'échelle pour les ordonnées ?

                                • [^] # Re: Curieux la base de donnée

                                  Posté par  (site web personnel) . Évalué à 2.

                                  Nan, mais tu peux cliquer sur un point dans le graphe pour avoir la valeur. J'ai fait les graphes à l'arrache.

                                  Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Charge CPU trop élevée

    Posté par  . Évalué à 0.

    Salut !

    Pour une raison obscure, lorsque je démarre lutim la charge CPU est très élevée. Je suis obligé de le kill pour pouvoir faire autre chose. J'ai suivi les instructions pour l'installer en installant carton depuis les dépôts de ma distro.

    Une idée pour résoudre le problème ?
    Merci !

    • [^] # Re: Charge CPU trop élevée

      Posté par  (site web personnel) . Évalué à 2.

      Hum, bizarre.

      Stoppe ton serveur avec
      carton exec hypnotoad -s script/lutim

      Puis lance le serveur de développement
      carton exec morbo -s script/lutim -l http://IP_DANS_LUTIM.CONF:PORT

      Est-ce que ça fait la même chose ?

      Tu es sur quelle distro ? Tu peux m'envoyer les logs (dans le répertoire logs) à admin [AT] lut.im ?

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: Charge CPU trop élevée

        Posté par  . Évalué à 1.

        En dev, lutim se lance correctement, fonctionne et aucune surcharge du CPU. J'ai oublié de préciser qu'en prod, le serveur était inaccessible. Ma distro est Linux Mint 16.
        Je t'ai envoyé les logs par mail.

  • # Lien d'affichage ?

    Posté par  (site web personnel) . Évalué à 1.

    Question : Pourquoi est-ce que le lien d'affichage pour mon image http://lut.im/kN2y6vph télécharge l'image, comme le lien http://lut.im/kN2y6vph?dl ?

    • [^] # Re: Lien d'affichage ?

      Posté par  (site web personnel) . Évalué à 3.

      Mauvais comportement de ton navigateur par rapport à l'en-tête Content-Disposition (voir ici).

      D'après le lien que je donne, y a que Firefox qui a l'air de bien comprendre l'en-tête. Mon chromium me le télécharge, que je le mette le header ou pas, et quelque soit la syntaxe (espace, quotes, etc) que j'utilise.

      Bref : ouvre un ticket… chez le créateur de ton browser ! :)

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: Lien d'affichage ?

        Posté par  (Mastodon) . Évalué à 1.

        Je suis moyennement fan de lire une telle réponse. Oui, on sait, les normes c'est pas fait pour les chiens. Mais l'immense majorité des utilisateurs (et quand je dis ça, j'inclue aussi les power users que nous sommes ici sur LinuxFR) n'a aucune idée de ce que tu racontes, ne comprendra pas, et en attendant… ça marche pas.

        Il est évident qu'il y a des moyens à ta disposition pour résoudre ce pb, envisage-le sérieusement, ça pénalise l'utilisation de ton site (je ne vois pas le bug étant sous Firefox, mais j'imagine comme c'est pénible d'avoir un clic de plus à faire pour avoir, au final, l'image) et ça entrave son but premier : résoudre élégamment un soucis du quotidien d'une partie de l'humanité :)

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Lien d'affichage ?

          Posté par  (site web personnel) . Évalué à 3.

          Il est évident qu'il y a des moyens à ta disposition pour résoudre ce pb, envisage-le sérieusement,

          Évident, évident… pas tant que ça, j'y ai déjà passé du temps et j'ai pas trouvé de solution.

          EDIT: En fait c'est plutôt au niveau du Content-Type que ça va pas. Et à cause de la nouvelle détection du type MIME (qui fait parfois des mimetype bizarres). J'ai trouvé où ça ne va pas.
          C'est corrigé en prod, mais le commit viendra plus tard dans la journée parce que j'ai une montagne de commits à faire et qu'il faut encore que je merge la branche dév après ça.

          ça entrave son but premier : résoudre élégamment un souci du quotidien d'une partie de l'humanité :)

          C'est vrai. Mea culpa, mea maxima culpa.

          Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Pas de limitation de durée ?

    Posté par  (site web personnel) . Évalué à 1.

    Par défaut je vois que le réglage est "pas de limitation de durée". Tu n'a pas peur que à force ça remplisse ton serveur ? Je veux dire, déjà, 1 an ça parait super long pour ce genre de service.

    En fait pour mon premier test je me suis fait "avoir" parce que je pensais pas que quand j'aurais sélectionné l'image à allait l'envoyer direct, je penser changer la durée avant. Du coup tu va te retrouver avec mon image inutile pour toujours sur ton serveur…

    Sinon c'est super comme service, c'est vraiment un truc que je vais mettre en bookmark et dont j'aurais l'utilité.

    • [^] # Re: Pas de limitation de durée ?

      Posté par  (site web personnel) . Évalué à 4.

      Tu n'a pas peur que à force ça remplisse ton serveur ?

      Si, un peu, mais je vais déménager sur un serveur Framasoft. Je dois implémenter une limite de taille du total des fichiers, je verrais ça à ce moment.

      En fait pour mon premier test je me suis fait "avoir" parce que je pensais pas que quand j'aurais sélectionné l'image à allait l'envoyer direct, je penser changer la durée avant.

      Y a un ticket qui demande à pouvoir changer une fois que c'est poussé. Yapluka. Plus tard.

      Sinon c'est super comme service, c'est vraiment un truc que je vais mettre en bookmark et dont j'aurais l'utilité.

      Merci, ça fait plaisir.

      Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

      • [^] # Re: Pas de limitation de durée ?

        Posté par  . Évalué à 0.

        Niveau place je ne sais pas combien tu as mais à titre de comparaison Toile Libre, qui est je pense relativement connue, n'utilise que 72Go pour ses images et il n'est pas possible de les supprimer.

        • [^] # Re: Pas de limitation de durée ?

          Posté par  (site web personnel) . Évalué à 3.

          Oh bah ça va alors ! Il m'en reste plus que ça, j'ai de quoi faire de la place, et en plus je vais migrer vers un serveur Framasoft. Je suis tranquille :)

          Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.