[WAREZ] Téléchargez le code source de pix !!1
Attention, j’ai viré TOUT ce qui ressemble à du cosmétique pour ne garder que l’essentiel (afin de vous forcer à bosser un peu et/ou de vous permettre d’en faire ce que vous voulez).
Si vous arrivez à installer le bordel ça ressemblera à ça : http://proto.pix.nofrag.com
C’est entièrement fonctionnel, il n’y a simplement aucun texte et aucune mise en page. :)
Sont inclus :
- Un bout de config pour lighttpd (facile à adapter pour apache : il faut principalement faire une règle de réécriture qui renvoie (.*)\.html sur /index.php/$1).
- Le code du site web (PHP5 requis à cause de la fonction image_type_to_extension, mais qu’on pourrait facilement réécrire)
- Le schéma de la base de donnée (MySQL)
- Un filtre en python qui prend en entrée standard les logs du serveur web, qui les traite en base de donnée, et qui recrache en sortie les logs tels quels
Ce qu’il manque :
- Les 2 scripts shell qui effacent les fichiers inutilisés et rendent inaccessibles ceux qui consomment trop.
- La documentation (mais bon il y a moins de 10 fichiers en tout, ils sont assez court, il suffit de les lire)
Le lien : http://proto.pix.nofrag.com/protopix.tgz
10 août 2007 à 19:08 Citer
Sauce link ?
10 août 2007 à 19:10 Citer
Pas con.
10 août 2007 à 19:24 Citer
Mais en fait, skoot = Ced ?
10 août 2007 à 19:30 Citer
Heu non skoot il est admin système et CeD il fait "que" du code pour NF (webdesign)
10 août 2007 à 19:32 Citer
On sait tous les deux faire du PHP, sauf que je suis bien plus fort que lui. :-)
CeD il a fait le web et les blogs, moi j’ai seulement fait le moteur de pix et des quiz. Et même sur ces deux trucs là c’est ced qui a rendu le truc agréable à utiliser (sans lui je vous assure que pix ressemblerait BEAUCOUP à proto.pix).
10 août 2007 à 19:47 Citer
aww, merci pour tout ça !
Et j’ai juste une question HS par rapport à pix. NF utilise lighttpd et php, j’imagine que php est utilisé en fastcgi. Comment tu fais pour éviter que les autres hébergés tapent dans les fichiers des autres (par le biais d’include par exemple) ? Le seul moyen que j’ai trouvé c’était de spawner des process php propre à chaque site mais c’est caca au final si t’as plusieurs dizaines de sites…
10 août 2007 à 19:59 Citer
On était en safe_mode y a encore pas si longtemps ce qui évitait le genre de chose dont tu parles. J’ai du virer le safe_mode depuis ma dernière mise à jour de PHP parce que les sessions ne marchaient plus… j’ai pas cherché plus que ça d’où venait le problème. Ca ne me traumatise pas trop parce qu’on a à peu près confiance dans nos hébergés d’une part, et qu’on va s’en débarrasser d’autre part. :)
10 août 2007 à 20:35 Citer
Ha ! D’accord. J’ai pas envie d’utiliser safe_mode parce que ce n’est plus supporté (et ça va être viré de php6)
10 août 2007 à 20:51 Citer
/me wants une update de pix.nf qui fait ça http://blogs.nofrag.com/pangel/2007/avr/07/27170-comment-linker-des-images-sans-se-faire-chier/
10 août 2007 à 21:21 Citer
ouais ce serais effectivement sympa. car imgred fait le menage assez souvent. c’est plus une demo qu’autre chose, leur truc.
ils filent meme gentilment le script utilise (php/sql) : http://imgred.com/Code.html
ca doit pas etre bien long a adapter pour juste y ajouter le systeme des repertoires…
edit : j’avais oublie : siouplait. t’es pas un esclave codeur indien.
et merci pour les sources au fait, ca me servira surement un de ces jours.
10 août 2007 à 23:20 Citer
C’est une chouette idée, et je vais regarder. Mais avant même de lire leur code je suis à peu près sûr que ça supposerait de casser un des principes fondamentaux de pix : ne servir (quasiment) que du contenu statique. Pix ça pourrait tourner sur un Celeron 500, et c’est ça qui est rigolo. Quand on demande une image on va la chercher directement sur le disque sans avoir besoin de PHP ou de MySQL; Il n’y a que lors de l’upload qu’on a besoin de PHP, et MySQL me sert uniquement pour enregistrer le traffic (avant je faisais sans).
A ce propos l’import des anciennes images est terminé (si il y a des liens cassés c’est qu’un truc s’est pas bien passé, et vous n’avez plus qu’à ré-uploader vos images), et voilà l’utilisation du CPU faite par la machine (un P4) :
CPU states: 0.0% user, 0.0% nice, 1.9% system, 0.4% interrupt, 97.8% idle
0.0% user :) Les seuls truc qui bossent, ce sont le disque et la carte réseau.
Cela dit dés que imgred.com répond, j’irais voir. :)
11 août 2007 à 0:06 Citer
Si j’ai le temps en milieu de semaine prochaine j’y songerais, cependant un url rewriting pour lors d’un get vers http://pix.nofrag.com/http://www.google.fr/intl/fr_fr/images/logo.gif redirigerais vers le fichier nommé http__www.google.fr_intl_fr_fr_images_logo.gif voire mieux vers http__www.google.fr/intl_fr_fr_images_logo.gif
Une simple expression régulière dans un .htaccess suffit (ne marche pas sur les *.free.fr si je me souviens bien), et je suis certain que ça prendrais aucune ressource, php n’étant pas appelé, avec un tri automatique selon le site. On pourrait faire plus une expression un poil plus complexe pour optimiser encore la recherche sur le filesystem.
Dans le cas du premier link, une simple gestion de l’erreur 404 sur pix.nofrag.com - toujours le .htaccess -, et on a un script php qui vérifie l’url d’origine demandée, fais un @file et l’enregistre sous le nom que l’url rewriting utiliserait.
Je sais pas si je me suis bien fait comprendre, mais cela me parait pas vraiment beaucoup plus dur niveau code, et serait pas plus consomateur de ressources pour autant.
11 août 2007 à 0:20 Citer
bien le coup du .htaccess!
par contre renvoyer sur le repertoire construit avec le hash c’est chaudcouille.
la seule solution (sale) static que je vois, c’est un rep unique de liens symboliques contenant tous les http__www.google.fr_intl_fr_fr_images_logo.gif.
mais en temps d’acces ca doit puer grave.
sinon voila le code:
http://209.85.129.104/search?q=cache:QZWrmHvtSnUJ:imgred.com/Code.html+http://imgred.com/Code.html&hl=fr&ct=clnk&cd=1&gl=fr&client=firefox-a
11 août 2007 à 0:36 Citer
Merci pour le code source. J’adore les projets qui tiennent en quelques lignes de code !
Pour l’histoire de imgred, ca serait pas jouable de faire le md5 sur le lien complet et non pas sur l’image ?
Si l’image correspondant n’est pas sur le disque
aller la downloader;
créer l’image sur le serveur en fonction du md5 du lien demandé;
Sinon
afficher l’image
En tout cas c’est amusant, bravo d’être resté sur l’idée d’un moteur très light.
11 août 2007 à 1:27 Citer
Oui tout ça pourrait marcher, mais on perd un autre intérêt de pix qui est de ne stocker qu’une seule fois les images. Quels que soient les différents noms qu’une image aura avant son upload, sur notre disque elle sera toujours au même endroit puisque je construit son nom à partir du hash MD5 du fichier (en ignorant complètement son nom d’origine). 1000 personnes peuvent uploader la même image (nommée différemment) 1000 fois, elle ne sera écrite sur le disque que la première fois.
Et puis il y a quand même un truc un peu bizarre avec imgred, c’est que ça suppose qu’une URL donnée pointera toujours vers la même image. Une fois l’image en cache, elle est en cache, et si on l’a déjà on ne va pas la rechercher. Sur pix vous pouvez uploader 2 images portant le même nom, si elles ne sont pas identiques elles seront évidemment stockées à des endroits différents.
Et enfin, si c’est le serveur qui va chercher l’image il devient impossible de connaître l’IP de la personne qui a demandé à ce que j’aille la chercher (au mieux j’ai le referer, ce qui est rarement très utile). Et ça c’est quand même très problématique.
Finalement imgred c’est un proxy. :-)
11 août 2007 à 1:59 Citer
Je n’aurais pas réussi à dormir avec ça en tête, alors j’ai fait de façon très light et très crade un code :
err404.php
[code]<?php
$source=substr($_SERVER['REQUEST_URI'], 1);
$nohttp=substr($source, 7); //on vire "http://" parce que ne sera pas supporte par le system de fichiers
@mkdir(’pics/’.substr($nohttp, 0, strrpos($source, ‘/’)), 0700, true); //on vire le nom du fichier, et on cree de facon recursive tous les dossiers
copy($source, ‘pics/’.$nohttp);
header("Content-type: image/jpeg");
readfile(’pics/’.$nohttp);
?>[/code]
A ne surtout pas utiliser tel quel sur un vrai serveur, j’ai fais les tests sur mon réseau local, et je ne prendrais la responsabilité des problèmes que peuvent causer des failles aussi béantes, etc.
J’ai aussi carément oublié que lighttpd ne supportais pas de .htaccess pour alléger le serveur, on mettra ça sur le compte de la fatigue. Donc voici non pas un .htaccess mais un bout de mon fihier de config lighttpd pour réaliser ce truc :
lighttpd.conf
[code]url.rewrite-once += (
"^/http://(.+)$" => "/pics/$1",
)
server.error-handler-404 = "/pix404.php"[/code]
Ca fonctionne parfaitement, si l’url de l’image a déjà été linkée, c’est qu’il y a un fichier, et donc lighttpd le lire directement comme le fait déjà pix. Si ce n’est pas le cas, erreur 404 => le script php télécharge l’image et la copie sur le serveur.
Seulement, ça a deux inconvénients.
Le premier, est qu’au bout de 1000 sites différents linkés (au niveau des dossiers nofrag.com, jv.com, …), on aura un ralentissement puisque peut de système de fichiers sont réellement capables de gérer un tel nombre de fichiers. Je ne sais pas du tout de quel ordre il sera, cependant on perd l’interrêt de pix d’être ultra light, puisque le filesystem va ramer. Ok le cpu user sera toujours à 0, mais le cpu system grimpera.
Ensuite, comme l’a dit skoot, deux fichiers étants la même image, hébergés à différents endroits, sera en double, voir vite beaucoup plus. La seule solution que je vois, et lors de l’execution de err404.php, de garder en base de données mysql/sqlite chaque image, leur hash md5. Dans le cas de hash clone, il suffirait de créer un lien symbolique plutot que de recopier une deuxième fois le même fichier. Ca fait toujours un fichier de plus, mais on passe de ~20000 octets à 4096 octets pour les doublons, et on ne perd toujours pas en vitesse.
Par contre, là où je ne suis pas d’acord c’est sur la tracabilité : lors de l’execution de err404.php il est très bien possible bien sur de garder dans la table sql des fichiers, l’ip de la personne l’ayant demandé.
Cela dit, je dois avouer qu’en fait imgred n’a pas de réelle utilité, si ce n’est aider les fénéants à rester fénéants. Pourquoi pas un simple <input type="text" name="url" /> en plus du champ file dans http://pix.nofrag.com/ ? Si ce nouveau champ est rempli avec une url d’image, et pas le champ file, dans ce cas le script php irait chercher sur l’url l’image en question, et up comme le fait déjà pix? Ca serait juste une façon qui permettrait de voler une image sans devoir l’enregistrer sur son propre disque dur.
Bref c’est vrai, ça sert pas à grand chose, si ce n’est le petit plus d’avoir la possibilité de donner une image d’un site, sans risque de la voir se transformer en 404 le lendemin.
11 août 2007 à 2:26 Citer
Un champ permettant d’entrer une URL plutôt qu’une image serait effectivement possible sans rien "casser", j’y ai pensé. Mais je m’interroge sur l’utilité de la chose : Il faudra quand même aller sur pix, copier l’URL, et récupérer le nom fabriqué par le site. On évite donc juste l’étape consistant à enregistrer l’image sur le disque…
On est au final assez loin de la fonctionnalité d’imgred qui permet de sauter complètement l’étape consistant à passer sur le site, et c’est précisément ça qui rend le truc si élégant. Tiens et maintenant que j’y pense, un système à la imgred ça voudrait aussi dire qu’on ne verrai pas les googleadds. :-)
Concernant la tracabilité : dans le cas d’une URL à la imgred, les seuls IP que j’ai ce sont celles des visiteurs qui demandent à voir l’image (et il se trouve que le premier à demander l’image va nous forcer à aller la chercher), mais à aucun moment je n’ai la possibilité de savoir qui a fait ce lien me demandant d’aller chercher une image. Et au final la personne qui a mis l’image en ligne sur pix, c’est pix.
Bref ce sont deux choses bien différentes. Pix est un hébergeur, alors qu’imgred est un proxy. La seule façon élégante de rajouter une fonctionnalité à la imgred serait de le coder sous forme de surcouche (donc dans un autre site), qui utiliserait pix pour le stockage. Le rôle de cette surcouche serait simplement de maintenir une correspondance URL réelle -> URL sur pix (et pour ce genre de chose, une base de donnée est encore ce qui se fait de mieux) avec un TTL histoire de rafraîchir les images de temps en temps.
Puisque c’est une surcouche, finalement n’importe qui peut déjà le faire sur son propre hébergement : uploader une image sur pix via un script c’est pas très compliqué (c’est un envoi de formulaire), et on n’a même pas besoin de récupérer l’URL générée puisque le hash MD5 vous pouvez aussi bien le calculer vous-même (les URL de pix sont prédictibles, la nomenclature est toujours la même).
Je vais peut être faire ça demain pour voir si c’est aussi facile que je pense. :)
22 août 2007 à 16:56 Citer
Merci bien à toi pour ce code, même si je m’en suis pas servis.. :p
pour le coup du hotlink, j’ai fais un script de miniature assez pratique..
http://img.borkmadjai.com/min.php?pic=http://machin.jpg
on peu passer comme paramètre h= pour définir la hauteur de l’image (auto-redimension)
on peu passer aussi text= pour modifier le img.borkmadjai.com en haut à gauche
merci pour l’idée du md5 en tous cas…
ça ma bien servis et c’est vraiment pas con du tous..
congrat skoot pour pix :]
8 mai 2008 à 20:51 Citer
Super, mais lien mort :(
j’avais deja telecharger la source et reutiliser la fonction de creation de thumbnails pour un hebergement d’image perso, mais maintenant que je suis sous lighttpd et rencontrant des pb avec la limite de taille des fichiers je reviens ici chercher la source mais erreur 404 :(