Oui, le lecteur de vidéo provoque des requêtes non-HTTPS lors de la lecture de la vidéo. C'est un problème connu de l'hébergeur que l'on utilise pour la vidéo; on a pas trouvé de workaround pour l'instant.
On cherche quelqu'un qui ne parte pas au bout de 2 mois parce qu'une autre boite lui a fait une meilleur proposition, donc on a aucun intérêt à payer au rabais. Je ne sais pas si je peux donner les chiffres, mais il n'y a pas d'intersection entre notre fourchette et ta fourchette ;)
De plus, quand je lis ça: "Bonne rémunération (selon expérience)" mon détecteur de bullshit s'allume et me dit "rémunération merdique, passe ton chemin."
Ha mince, je ne mettrais plus ça alors, merci pour le feedback!
La rémunération est plutôt bonne en réalité, pour un développeur senior. On veut quelqu'un qui ait envie de rester pour la qualité du poste, l'équipe, et aussi la rémunération. "Selon expérience" = on a une fourchette, et l'expérience influence la position dans cette fourchette.
Oui j'ai vu ça, mais si je comprend bien ça produit un journal capable de re-créer entièrement les données (pas seulement à partir du dernier dump). Ça doit faire un journal énorme, et mettre beaucoup de temps à importer.
Je ne peux plus éditer mon commentaire précédent, j'ajoute mes question dans un nouveau commentaire:
Le code du serveur a l'air super simple (et ça donne envie de faire du Go :) ). Est-ce que Go et/ou pat gère les requêtes concurrences ? Est-ce que si un serveur distant met un certain temps à répondre à une requête ça peut bloquer les autres requêtes ?
Il permet de dumper le contenu sur le disque de temps en temps, et de journaliser les commandes envoyées au serveur, mais on est loin d'une garantie de persistence/consistence des données.
Ça n'a pas l'air très simple à mettre en place. Et si le serveur crash brutalement, des données sont perdues.
Enfin, img n'est pas un proxy ouvert sur Internet ; il n'accepte de servir que les images connues de LinuxFr.org dont le poids fait moins de 5 Mo.
D'après le code, ça fonctionne de cette façon:
- quand on poste un commentaire, ça enregistre l'url des images du commentaire dans un serveur redis
- quand on demande une image au proxy, il vérifie que l'url existe dans redis
Redis n'est pas un système de stockage persistent, qui est bien pour stocker des données volatiles, mais les URLs des images ne sont pas une donnée volatile.
Est-ce que vous avez envisagé une solution à base de signature des URLs ? Si linuxfr signe les URLs des images avec HMAC par exemple, le proxy peut vérifier que l'URL a bien été générée par linuxfr, et autoriser la requête. Et du coup pas besoin de stocker une liste d'URLs.
Bonne idée. Un autre problème des images externes, qui n'est pas mentionné ici, est que l'image peut demander une identification HTTP. Le browser affiche alors un dialogue demandant un nom d'utilisateur et un mot de passe. Certains utilisateurs pourrait y entrer leurs informations de connexion de linuxfr, que le vilain pirate peut récupérer.
sous-domaine pour éviter que le JavaScript embarqué dans les images en SVG puisse servir de vecteur d'attaque contre le site.
L'utilisation d'un domaine séparé pourrait être une bonne idée, il me semble qu'en jouant avec document.domain un script sur img.linuxfr.org pourrait avoir accès à linuxfr.org (le DOM, localStorage, cookie, etc). Ça ne fonctionne que si linuxfr.org fait un document.domain=document.domain avant, mais une nouvelle fonctionnalité de linuxfr dans le futur pourrait introduire ça en oubliant que cela rend le site vulnérable.
img.linuxfr.org pourrait également avoir accès à des cookies de linuxfr.org via document.cookie.
Autre chose, en voulant essayer j'ai remarqué que img.linuxfr.org ne fonctionne pas lors des previews (le proxy retourne un 404).
Cet outil est capable de sauvegarder directement en copiant les fichiers de la base de donnée, sans arrêter le serveur. (Il fait ça en surveillant le journal, etc.)
Il est aussi capable de faire des backups incrémentaux.
Du coup c'est beaucoup mieux que des dumps sql:
sauvegardes plus rapides
restaurations beaucoup plus rapides
taille des sauvegardes
la DB n'est jamais verrouillée
les données sont consistantes
Pour planifier des backups, gérer les backups incrémentaux, gérer les backups de serveurs distants, etc il y a xtrabackup-manager, qui est un frontend CLI à xtrabackup.
Comme alternatives à GNOME3 il y a MATE [1], qui est un fork de GNOME2 pour ceux qui n'aiment pas beaucoup GNOME3, poussé par Mint Linux [2], et Cinnamon [3] (poussé par Mint Linux aussi).
elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur
C'est vrai ça ? ça doit être très lourd de maintenir une Arch Linux en état de fonctionnement au fil des mises à jour.
Sur Debian, et probablement d'autres, ça fonctionne de la façon suivante:
Si le fichier de config n'a pas été modifié par l'admin, il est remplacé par la nouvelle version
Sinon, le système laisse le choix à l'admin (remplacer, garder la version actuelle, comparer, etc)
Du coup je laisse la distribution s'occuper des fichiers de config dont je ne m'occupe pas moi même (95% des fichiers dans /etc), et pour le reste la distrib me prévient.
Posté par __o .
En réponse à la dépêche Petit état des lieux du NoSQL.
Évalué à 1.
Dernière modification le 09 mai 2012 à 12:34.
Tu parles de quel genre d'hébergeur ? Parce que sur les hébergements mutualisés php, ça n'a pas l'air d'être le cas. Par exemple chez OVH l'hébergement à 1.99€ a 25Go d'espace disque ;)
Tout à fait, par contre il semblerait qu'ils utilisent quand même MySQL pour “pretty much every user interaction: likes, shares, status updates, alerts, requests, etc” [1]
Posté par __o .
En réponse à la dépêche Petit état des lieux du NoSQL.
Évalué à 10.
Dernière modification le 07 mai 2012 à 15:26.
Les SGBD relationnels sont traditionnellement optimisés pour fonctionner dans un environnement où les données et même les indexes sont bien plus gros que la RAM. Ces SGBD font donc tout pour limiter le nombre d'I/O, essayer de lire les données séquentiellement, etc.
Beaucoup de bases NoSQL sont au contraire optimisées pour fonctionner en RAM (en particulier les BDD clé-valeur et documents), ou assument que les données sont cachées en RAM par le système. Ça peut poser de sérieux problèmes le jour où les performances s'écroulent d'un coup parce que les données sont devenues plus grosses que la RAM.
Au final les SGBD traditionnels sont plus performants qu'un certain nombre de bases NoSQL, lorsque les données doivent être lues sur le disque.
Il y en a qui en reviennent [1]
Notons en particulier que la plupart des plus gros sites web ont quitté le monde relationnel (Google, Facebook, Twitter, Amazon)
Les systèmes NoSQL utilisés par ceux là répondent plus à des problèmes de haute disponibilité, de scalabilité et de souplesse que de performances: Fragmentation (sharding) automatique, changement de schema à chaud, etc.
Twitter utilise encore MySQL comme stockage principal [2].
Youtube utilise MySQL également. D'ailleurs ils ont démarré un projet intéressant pour gérer automatiquement le sharding, etc [3].
Facebook aussi utilise MySQL pour beaucoup de choses [4].
php-fpm permet de définir plusieurs "pools", avec des configs différentes (user, nombre de process, chroot, config php; tout en fait), et qui écoutent sur un socket tcp/unix différent.
Tu configure chaque vhost pour utiliser le bon pool (en spécifiant l'url de la socket).
FastCGI a un peu d'overhead par rapport à mod_php (vu que le serveur http et fastcgi communiquent via une socket), mais c'est négligeable comparé au temps d'exécution des scripts (par sûr que ça se voit sur un benchmark).
[^] # Re: Langage ou framework ?
Posté par __o . En réponse au sondage Quel langage utilisez-vous sur vos serveurs pour vos applications web ?. Évalué à 5.
+1 pour language vs framework.
Pour Ruby, il y a au moins Sinatra
[^] # Re: Que fait ta boite?
Posté par __o . En réponse au message [offre d'emploi] Développeur backend expérimenté. Évalué à 2. Dernière modification le 21 juin 2014 à 22:36.
Oui, le lecteur de vidéo provoque des requêtes non-HTTPS lors de la lecture de la vidéo. C'est un problème connu de l'hébergeur que l'on utilise pour la vidéo; on a pas trouvé de workaround pour l'instant.
[^] # Re: Que fait ta boite?
Posté par __o . En réponse au message [offre d'emploi] Développeur backend expérimenté. Évalué à 1.
On cherche quelqu'un qui ne parte pas au bout de 2 mois parce qu'une autre boite lui a fait une meilleur proposition, donc on a aucun intérêt à payer au rabais. Je ne sais pas si je peux donner les chiffres, mais il n'y a pas d'intersection entre notre fourchette et ta fourchette ;)
[^] # Re: Que fait ta boite?
Posté par __o . En réponse au message [offre d'emploi] Développeur backend expérimenté. Évalué à 1.
c.f. la réponse de chimrod :)
Ha mince, je ne mettrais plus ça alors, merci pour le feedback!
La rémunération est plutôt bonne en réalité, pour un développeur senior. On veut quelqu'un qui ait envie de rester pour la qualité du poste, l'équipe, et aussi la rémunération. "Selon expérience" = on a une fourchette, et l'expérience influence la position dans cette fourchette.
[^] # Re: Que fait ta boite?
Posté par __o . En réponse au message [offre d'emploi] Développeur backend expérimenté. Évalué à 1.
Tout bon :) On fait aussi de l'enrichissement sur les données, du crawling, etc.
# Temporairement
Posté par __o . En réponse au message Comment faire pour s'auto-héberger (ip publique) derrière un routeur qu'on ne peut administrer. Évalué à 3.
Si c'est un besoin temporaire: http://progrium.com/localtunnel/
# Il y a libre et libre
Posté par __o . En réponse au journal Radioamateurisation du libre. Évalué à 9.
Il suffit de voir l'activité sur Github pour se rendre compte que le libre est en très bonne forme.
Est-ce que c'est l'esprit de la FSF, GNU, GPL; je ne sais pas. Mais l'open source, le partage de code, la coopération sont bien là.
[^] # Re: redis vs signature
Posté par __o . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 0.
Oui j'ai vu ça, mais si je comprend bien ça produit un journal capable de re-créer entièrement les données (pas seulement à partir du dernier dump). Ça doit faire un journal énorme, et mettre beaucoup de temps à importer.
[^] # Re: redis vs signature
Posté par __o . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 1.
Si elle se débrouillait vraiment bien, elle ferait des journaux qui commencent là où s'arrêtent les dumps.
Parce qu'avoir un backup fait entièrement de journaux, j'imagine que ça doit être énorme.
[^] # Re: Requêtes simultanées
Posté par __o . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 2.
Génial :) Je vais jouer un peu avec Go je crois
# Requêtes simultanées
Posté par __o . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 3.
Je ne peux plus éditer mon commentaire précédent, j'ajoute mes question dans un nouveau commentaire:
Le code du serveur a l'air super simple (et ça donne envie de faire du Go :) ). Est-ce que Go et/ou pat gère les requêtes concurrences ? Est-ce que si un serveur distant met un certain temps à répondre à une requête ça peut bloquer les autres requêtes ?
[^] # Re: origine
Posté par __o . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 5.
Oui, en fait l'url des images est
//img.linuxfr.org/img/hex(url d'origine)
.Exemple:
A comme URL:
http://img.linuxfr.org/img/68747470733a2f2f613234382e652e616b616d61692e6e65742f6173736574732e6769746875622e636f6d2f696d616765732f6d6f64756c65732f61626f75745f706167652f6f63746f6361742e706e673f31333135393238343536
En décodant la partie après /img/ (via http://www.string-functions.com/hex-string.aspx par exemple) on trouve:
https://a248.e.akamai.net/assets.github.com/images/modules/about_page/octocat.png?1315928456
[^] # Re: redis vs signature
Posté par __o . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 1.
Il permet de dumper le contenu sur le disque de temps en temps, et de journaliser les commandes envoyées au serveur, mais on est loin d'une garantie de persistence/consistence des données.
Ça n'a pas l'air très simple à mettre en place. Et si le serveur crash brutalement, des données sont perdues.
# redis vs signature
Posté par __o . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 3.
D'après le code, ça fonctionne de cette façon:
- quand on poste un commentaire, ça enregistre l'url des images du commentaire dans un serveur redis
- quand on demande une image au proxy, il vérifie que l'url existe dans redis
Redis n'est pas un système de stockage persistent, qui est bien pour stocker des données volatiles, mais les URLs des images ne sont pas une donnée volatile.
Est-ce que vous avez envisagé une solution à base de signature des URLs ? Si linuxfr signe les URLs des images avec HMAC par exemple, le proxy peut vérifier que l'URL a bien été générée par linuxfr, et autoriser la requête. Et du coup pas besoin de stocker une liste d'URLs.
# Bonne idée
Posté par __o . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 7.
Bonne idée. Un autre problème des images externes, qui n'est pas mentionné ici, est que l'image peut demander une identification HTTP. Le browser affiche alors un dialogue demandant un nom d'utilisateur et un mot de passe. Certains utilisateurs pourrait y entrer leurs informations de connexion de linuxfr, que le vilain pirate peut récupérer.
L'utilisation d'un domaine séparé pourrait être une bonne idée, il me semble qu'en jouant avec document.domain un script sur img.linuxfr.org pourrait avoir accès à linuxfr.org (le DOM, localStorage, cookie, etc). Ça ne fonctionne que si linuxfr.org fait un
document.domain=document.domain
avant, mais une nouvelle fonctionnalité de linuxfr dans le futur pourrait introduire ça en oubliant que cela rend le site vulnérable.img.linuxfr.org pourrait également avoir accès à des cookies de linuxfr.org via document.cookie.
Autre chose, en voulant essayer j'ai remarqué que img.linuxfr.org ne fonctionne pas lors des previews (le proxy retourne un 404).
# Xtrabackup et Xtrabackup-manager
Posté par __o . En réponse au journal La sauvegarde MySQL. Évalué à 2. Dernière modification le 29 juin 2012 à 12:04.
Une solution alternative est xtrabackup.
Cet outil est capable de sauvegarder directement en copiant les fichiers de la base de donnée, sans arrêter le serveur. (Il fait ça en surveillant le journal, etc.)
Il est aussi capable de faire des backups incrémentaux.
Du coup c'est beaucoup mieux que des dumps sql:
Pour planifier des backups, gérer les backups incrémentaux, gérer les backups de serveurs distants, etc il y a xtrabackup-manager, qui est un frontend CLI à xtrabackup.
[^] # Re: listes déroulantes sont toujours d'une longueur infinie
Posté par __o . En réponse au journal Détection de la syntaxe d'un langage informatique via un analyseur statistique naïf de type Bayésien. Évalué à 2.
Si tu codes en parlant à ta machine, je suis sûr que ça marche aussi.
Sinon, je sais pas comment tu codes, mais ça m'intéresse ;)
# listes déroulantes sont toujours d'une longueur infinie
Posté par __o . En réponse au journal Détection de la syntaxe d'un langage informatique via un analyseur statistique naïf de type Bayésien. Évalué à 3.
Quand la liste a le focus (ou quand elle est ouverte), tapes les premières lettres de ton langage, et regarde la magie :)
# Alternative à GNOME3
Posté par __o . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 3.
Comme alternatives à GNOME3 il y a MATE [1], qui est un fork de GNOME2 pour ceux qui n'aiment pas beaucoup GNOME3, poussé par Mint Linux [2], et Cinnamon [3] (poussé par Mint Linux aussi).
MATE est juste superbe.
[1] http://mate-desktop.org/
[2] http://linuxmint.com/
[3] http://cinnamon.linuxmint.com/
[^] # Re: Shard
Posté par __o . En réponse au journal F1, la base de données de Google pour remplacer Mysql. Évalué à 10.
Un fragment ?
# elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur
Posté par __o . En réponse à la dépêche Arch Linux signe ses paquets !. Évalué à 5.
C'est vrai ça ? ça doit être très lourd de maintenir une Arch Linux en état de fonctionnement au fil des mises à jour.
Sur Debian, et probablement d'autres, ça fonctionne de la façon suivante:
Du coup je laisse la distribution s'occuper des fichiers de config dont je ne m'occupe pas moi même (95% des fichiers dans /etc), et pour le reste la distrib me prévient.
[^] # Re: FS
Posté par __o . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 1. Dernière modification le 09 mai 2012 à 12:34.
Tu parles de quel genre d'hébergeur ? Parce que sur les hébergements mutualisés php, ça n'a pas l'air d'être le cas. Par exemple chez OVH l'hébergement à 1.99€ a 25Go d'espace disque ;)
[^] # Re: Budget RAM
Posté par __o . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 2.
Tout à fait, par contre il semblerait qu'ils utilisent quand même MySQL pour “pretty much every user interaction: likes, shares, status updates, alerts, requests, etc” [1]
[1] http://gigaom.com/cloud/facebook-shares-some-secrets-on-making-mysql-scale/
# Budget RAM
Posté par __o . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 10. Dernière modification le 07 mai 2012 à 15:26.
Les SGBD relationnels sont traditionnellement optimisés pour fonctionner dans un environnement où les données et même les indexes sont bien plus gros que la RAM. Ces SGBD font donc tout pour limiter le nombre d'I/O, essayer de lire les données séquentiellement, etc.
Beaucoup de bases NoSQL sont au contraire optimisées pour fonctionner en RAM (en particulier les BDD clé-valeur et documents), ou assument que les données sont cachées en RAM par le système. Ça peut poser de sérieux problèmes le jour où les performances s'écroulent d'un coup parce que les données sont devenues plus grosses que la RAM.
Au final les SGBD traditionnels sont plus performants qu'un certain nombre de bases NoSQL, lorsque les données doivent être lues sur le disque.
Il y en a qui en reviennent [1]
Les systèmes NoSQL utilisés par ceux là répondent plus à des problèmes de haute disponibilité, de scalabilité et de souplesse que de performances: Fragmentation (sharding) automatique, changement de schema à chaud, etc.
Twitter utilise encore MySQL comme stockage principal [2].
Youtube utilise MySQL également. D'ailleurs ils ont démarré un projet intéressant pour gérer automatiquement le sharding, etc [3].
Facebook aussi utilise MySQL pour beaucoup de choses [4].
Google utilise beaucoup MySQL également.
[1] http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb
[2] http://engineering.twitter.com/2012/04/mysql-at-twitter.html MySQL is the persistent storage technology behind most Twitter data: the interest graph, timelines, user data and the Tweets themselves.
[3] https://code.google.com/p/vitess/wiki/ProjectGoals
[4] http://gigaom.com/cloud/facebook-shares-some-secrets-on-making-mysql-scale/ MySQL handles pretty much every user interaction: likes, shares, status updates, alerts, requests, etc.
[^] # Re: Pour compléter...
Posté par __o . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 4.
php-fpm permet de définir plusieurs "pools", avec des configs différentes (user, nombre de process, chroot, config php; tout en fait), et qui écoutent sur un socket tcp/unix différent.
Tu configure chaque vhost pour utiliser le bon pool (en spécifiant l'url de la socket).
FastCGI a un peu d'overhead par rapport à mod_php (vu que le serveur http et fastcgi communiquent via une socket), mais c'est négligeable comparé au temps d'exécution des scripts (par sûr que ça se voit sur un benchmark).