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.
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).
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
- Instance officielle de LUTIm (2050 clics)
- Page github du projet (233 clics)
- Mojolicious (96 clics)
- Twitter Bootstrap (54 clics)
- Font Awesome (71 clics)
- Plugin JQuery de glisser/déposer (63 clics)
# LUTIm évolue déjà
Posté par Framasky (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
La mise à jour est tout ce qu'il y a de plus simple grâce à Mojolicious et son super serveur 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.
[^] # Re: LUTIm évolue déjà
Posté par Atem18 (site web personnel) . Évalué à 3.
C'est un serveur en carton ? :-P
[^] # Re: LUTIm évolue déjà
Posté par Framasky (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.
[^] # Re: LUTIm évolue déjà
Posté par Gui13 (site web personnel) . Évalué à 5.
ALL GLORY TO CARTON
ALL GLORY TO CARTON
ALL GLORY TO CARTON
(°)
# Fap machine.
Posté par Thomas Lecavelier . Évalué à -10.
Ayant lu le titre, j'ai tout de suite traduit par « FAP MACHINE ». :)
# questions légales
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 17 février 2014 à 11:50.
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?
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 Tonton Th (Mastodon) . Évalué à 3.
Tu en veux, du choquant ? C'est la Dirty Valentine !
[^] # Re: questions légales
Posté par Zenitram (site web personnel) . Évalué à 0.
Il est vrai que le sujet de chocabilité de la nimage est en retard d'un choc, les poils étant passés par la et remplacé le bleu/rose.
[^] # Re: questions légales
Posté par feth . É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 barmic . É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 Simon Morvan (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 feth . É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 Sufflope (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 barmic . É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 Kioob (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 Florent Zara (site web personnel, Mastodon) . Évalué à 10.
Ce ne sont pas juste des URL pas facile à trouver. Parmi les avantages :
Pour plus d'informations, voir la dépêche sur LinuxFr.org au sujet de ZeroBin
[^] # Re: questions légales
Posté par Stéphane Bortzmeyer (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 Framasky (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 Stéphane Bortzmeyer (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 Framasky (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 Framasky (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 Professeur Méphisto . Évalué à 7.
mais est-ce encore «privé» si tu offres un service à des tiers ?
[^] # Re: questions légales
Posté par Framasky (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 Zenitram (site web personnel) . Évalué à 4.
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.
Oui, mais la d'un coup ça fait moins "vendeur" que ce qu'il y a dans la dépèche ;-)
Je te rassure, moi non plus, juste que j'imagine des hauts le coeur chez certains.
[^] # Re: questions légales
Posté par sebas . Évalué à 3.
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 Framasky (site web personnel) . Évalué à 2.
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 sebas . Évalué à 2.
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 Benoît Sibaud (site web personnel) . Évalué à 4.
Reformulé dans la dépêche.
[^] # Re: questions légales
Posté par Framasky (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.
[^] # Re: questions légales
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Fait. Merci pour la réactivité.
[^] # Re: questions légales
Posté par Framasky (site web personnel) . Évalué à 2. Dernière modification le 17 février 2014 à 21:18.
Merci à toi pour la tienne !
Le chieur : l'IP de l'envoyeur n'est même plus dans les logs. Juste en bdd.
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 Benoît Sibaud (site web personnel) . Évalué à 3.
Nouvelle modification faite.
[^] # Re: questions légales
Posté par Framasky (site web personnel) . Évalué à 2.
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.
# Une proposition d'amélioration
Posté par Bidibulle2 . É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 Framasky (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 Juke (site web personnel) . Évalué à 1.
Dans le cadre de capture d'ecran anonyme, ça pourrait etre bien de pouvoir flouter certaines zones.
[^] # Re: Internet— Lut.im, un service d'hébergementd'images gratuit, libre et anonyme
Posté par Framasky (site web personnel) . Évalué à 8.
Euh, gimp fera très bien le job, faudra que tu floutes avant d'envoyer. Je voulais un truc simple, il est simple et le restera :)
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 Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8.
lut.im a un plugin Shutter et Shutter a une fonction très jolie de floutage (Shutter est le logiciel de capture d'écran recommandé).
# Limitation à des images
Posté par lolop (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 Framasky (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.
[^] # Re: Limitation à des images
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 4.
Cool, un nouveau Framatruc dans le Framacloud !
\o/
# Source de la nimage pour tester
Posté par Xinul . É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/
[^] # Re: Source de la nimage pour tester
Posté par Framasky (site web personnel) . Évalué à 2.
Certes, c'est vrai… J'ai oublié :p
Merci de l'avoir noté !
/me va aller se fouetter avec des orties
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: Source de la nimage pour tester
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Source ajoutée dans la dépêche.
# Curieux la base de donnée
Posté par jolitorax . Évalué à 4.
J'ai un peu de mal avec ça
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 Framasky (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 Kerro . Évalué à 3.
Perso, j'aime bien :-)
[^] # Re: Curieux la base de donnée
Posté par Framasky (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 Kerro . É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 Framasky (site web personnel) . Évalué à 3.
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.
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 Sufflope (site web personnel) . Évalué à 4.
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 BAud (site web personnel) . Évalué à 3.
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 xxxxxxpermettra 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 Framasky (site web personnel) . Évalué à 4.
Tu veux parler de Piwik peut-être :p Parce que bon, Piwigo, c'est une galerie de photo…
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).
multitail -e xxxxxx /var/log/production.logjeune 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 Sufflope (site web personnel) . Évalué à 1.
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 BAud (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 :
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 Framasky (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 zebra3 . É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 Framasky (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 Kerro . Évalué à 5.
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 Framasky (site web personnel) . Évalué à 3.
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 zebra3 . Évalué à 2.
Ç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 Dolmen (site web personnel) . Évalué à 2.
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 Framasky (site web personnel) . Évalué à 5.
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 Kerro . Évalué à 2.
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 Framasky (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 Kerro . Évalué à 2.
Ça ne fait pas débat, c'est toi le développeur… mais nous sommes sur Linuxfr hein :-)
.
Pas bête, effectivement.
.
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 Framasky (site web personnel) . Évalué à 2.
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 gnx . Évalué à 0.
Il n'y a pas d'échelle pour les ordonnées ?
[^] # Re: Curieux la base de donnée
Posté par Framasky (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 Claros . É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 Framasky (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 Claros . É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 Almacha (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 Framasky (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 gUI (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 Framasky (site web personnel) . Évalué à 3.
É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.
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 Almacha (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 Framasky (site web personnel) . Évalué à 4.
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.
Y a un ticket qui demande à pouvoir changer une fois que c'est poussé. Yapluka. Plus tard.
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 nanoseb . É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 Framasky (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.