Hi,

You can blog about absolutely anything as long as your writings are published under a free license (reminder: CC with NC and ND clauses are not considered free licenses). Take great care to mention the license on your blog though (typically in the footer).

Hello,

Oui, ça devrait être possible -- comme pour toutes les augmentations de quota, il suffit d'en faire la demande à l'équipe de modération. As-tu déjà une idée de la volumétrie requise ?

28

(2 replies, posted in Suggestions)

Hello,

Pour faire simple : absolument aucun plan dans cette direction.

29

(2 replies, posted in Help for TF users)

Hi,

The documentation may be a little old; rsync -a (i.e. rsync --archive) tries to enforce owner, group and permissions for all uploaded files, which is probably not what you want on TuxFamily's servers as:
1) user/groups are very likely to differ on TuxFamily's servers compared to your local machine
2) the virtual filesystem you can see over SSH has restrictions for chgrp operations
3) you probably do not want to enforce ALL permissions through rsync since the "setgid" flag we set on directories usually proves very, very useful for proper quota accounting and proper group assignment.

Long story short, just try running rsync without --archive, unless you have some private files that should remain "o-rwx" at all times. That said, I've just had a look at your files and it looks like a static website with no private file. I took the liberty to fix the permissions (which were fucked up by rsync, as it aborted too early):

chmod -R g+rwX,o+rX *
find -type f -print0 | xargs -0 -r chmod a-x

30

(3 replies, posted in Help for TF users)

Hi!

Indeed, our SSH service was down from ~00:15 UTC to ~14:24 UTC. It should now be up & running again. Sorry for the inconvenience :s

31

(2 replies, posted in Pub)

Hi librefan!

Thanks a lot for your kind review of our Gallicism-infested writings -- I am going to study your various improvements (using that web thingie at https://text-compare.com/ as it looks way more efficient than diff-so-fancy) with the intent of integrating them into the official website.

librefan wrote:

Merci beaucoup pour http://fingerprint.tuxfamily.org/
Il manque encore HTTPS mais ça va sûrement venir.

En effet : HTTPS apparaît dans la nuit suivant la création d'un espace web, d'où le délai, mais c'est désormais chose faite.

librefan wrote:

Et je n’ai pas bien compris:

(also, you should end up on "pastis")

Ça veut dire que si on s’est connecté en SSH à ssh.tuxfamily.org, on doit voir une invite contenant le nom du serveur pastis ?

Oui, tout à fait -- j'ai retouché le texte pour clarifier ça. Ça n'est pas un gage de sécurité, loin de là, mais ça reste une information utile.

librefan wrote:

Sur la FAQ, n’importe qui peut faire des modifications, j’aurais plus confiance dans une page de news que l’équipe de TF fait elle-même.

Ah oui, j'avais zappé cet aspect. C'est donc à nous de prendre ça en charge.

librefan wrote:

Pour l’anglais du poisson, j’ai lu rapidement mais il y a quelques hics. Veux-tu que je propose une correction? C’est peut-être un peu tard?

Un peu tard pour l'audience initialement visée mais pas trop tard pour le reste du monde. Sans même proposer une correction, nous faire une liste succinte des principaux hics nous aiderait déjà beaucoup. Dans la pratique, tu peux nous communiquer cela soit sur ce forum (dans un nouveau topic), soit par email à l'équipe de modération.

librefan wrote:

En fait la page https://www.tuxfamily.org/en/news/2008051401 est restée d’actualité jusqu’à Debian Jessie. Mais en passant à Debian Stretch, rien ne va plus ;)

Je pense que tu veux dire de Wheezy à Jessie, parce que Jessie, on y est toujours et Stretch, on n'y est pas encore :)

librefan wrote:

J’avais fait ça à l’époque:

ssh-keygen -lf key.pub

Mais est-ce que ça vérifie quelque chose (je ne crois pas) ou ça enregistre la clé, bonne ou pas bonne?

Ça ne vérifie rien, ça n'enregistre rien, ça ne fait qu'afficher le fingerprint de la clé publique contenue dans key.pub... Mais ça se cumule bien avec ta commande précédente :

ssh-keyscan 212.85.158.7 > tuxfamily-ssh.pub
ssh-keygen -lf tuxfamily-ssh.pub

Sortie:

2048 SHA256:2I7RpLvWCbEPDVMd3O9T3N/MVQlPWL1uVVxPYO1yvYc 212.85.158.7 (RSA)

Comme tu peux le constater, cela correspond exactement à ce que te sortait ton client ssh lors de ta première connexion.
Concernant la façon de vérifier : par définition, il n'y a pas de moyen magique de vérifier le fingerprint lors de la première connexion, il faut aller chercher la valeur attendue par un moyen tiers auquel on fait confiance ; par exemple, il faudrait idéalement qu'on maintienne une page dédiée sur la FAQ pour exposer ce fingerprint (et les autres). Auquel cas, c'est à la FAQ que tu ferais confiance.

librefan wrote:

Et en passant, votre poisson était instructif et rigolo à la fois :-D

Merci -- pas de faute d'anglais cette année ? :)

Hello,

librefan wrote:

Cette page n’a plus l’air d’actualité. https://www.tuxfamily.org/en/news/2008051401

Pour une news de 2008 (10 ans déjà !), ça n'est que moyennement choquant :)

librefan wrote:

The authenticity of host 'ssh.tuxfamily.org (212.85.158.7)' can't be established.
RSA key fingerprint is SHA256:2I7RpLvWCbEPDVMd3O9T3N/MVQlPWL1uVVxPYO1yvYc.

Ok, SHA256:2I7RpLvWCbEPDVMd3O9T3N/MVQlPWL1uVVxPYO1yvYc... Je te confirme que ce fingerprint est correct

librefan wrote:
ssh-keyscan 212.85.158.7

Cette commande-ci devrait te retourner :

212.85.158.7 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA1YP+v8DIEXdL8NCiTWe7EuSd2rkVd9GWspru2W8s1Be0tMcoDOvPUAQ0lzty/9X6rsPbCH/64tg8YVfdbgX5Bxt9+g1chFiDgpyDcvwUypI88UOKzde7u8KZeFnGegCti0J5ZU2r1s0fQyzaG3gNllbSz9zAuBoCrXEyOphToSh3Go141Bc8NxQn4DbIz6lpJmrHfcy1s8AzJZxeDfOy12XuJecY7QUGXIJkz9ffQJtlHIc+mbs+p+QDc2Is1GTMo57J2aeGVsKtwtOVRKasqqOQ++P4le/wMuHp47mbptAa8UGqRSx6Fge+27OixPQTcsq5w7L48VES0IHrECfp2Q==
librefan wrote:

Bon, j’ai fait ça et après? Comment je vérifie que c’est bien la bonne empreinte?

Merci! (et je veux bien rajouter l’info précise à la FAQ quand j’aurai tout compris)

Pour être franc, notre exposition des fingerprints est au mieux chaotique, au pire inexistante, comme le démontre une recherche du mot-clé "fingerprint" sur notre FAQ. N'hésite pas à compléter cette dernière, elle a été conçue dans cette optique.

Hello,

Je dirais que ton dépôt Git ne contient tout simplement pas de branche master à pousser. Quelle est la sortie de la commande suivante ?

git log --oneline --graph --color --decorate=short --all

Hello,

C'est effectivement une des limitations de la plateforme (la problématique se pose aussi pour Mercurial). Cela dit, tu peux nous demander de mettre en place les nouvelles descriptions par simple email adressé à l'équipe de modération.

38

(2 replies, posted in Help for TF users)

Hi,

Unfortunately, due to technical limitations, TuxFamily does not provide error logs. Our team is available over IRC and email (modo at staff.tuxfamily.org) to provide you with the relevant excerpts of error logs so that you may solve your technical issue.
If by chance this is about http://wiki.xmoto.tuxfamily.org/index.p … Main_Page, then you should simply quit using PHP short tags :)

Hello,

isa wrote:

Je pense avoir envoyé par FTP (avec filezilla) une page de test de mon site araok.net dans l'espace adapté (finissant par htdocs).

C'est probablement bon, oui (ok, je n'ai pas regardé).

Je pense avoir correctement configuré les DNS chez Gandi, registrar pour ce domaine, il y a plusieurs jours.

Ça semble bon aussi, oui.

La page de test ne s'affiche pas sur Internet.

Et pour cause : tu as indiqué à Gandi que le domaine araok.net était géré par TuxFamily... mais tu as oublié de demander à TuxFamily de gérer araok.net : il te faut demander, via notre panel, un objet "nom de domaine" pour araok.net. Accessoirement, tu peux supprimer araok.bzh si tu ne t'en sers plus.

En regardant sur VHFFS mes espaces web, je vois pour ce domaine araok.net la mention "Etat TLS : Etat global : Invalide".

C'est une conséquence, pas une cause : comme le processus de résolution DNS ne fonctionne pas, TuxFamily n'a pas pu obtenir de certificat TLS pour ton espace web. Commençons par régler le problème de DNS comme indiqué ci-dessus et ça ira déjà mieux (notamment, ça fonctionnera au moins en HTTP dans un premier temps).

40

(2 replies, posted in Help for TF users)

https://faq.tuxfamily.org/WebArea/En#How_to_use_it

Ok, je vois le genre. Tiens-nous au courant de tes progrès.

Conseils tardifs par rapport au refactoring et à tes fonctions à 80-91 lignes : l'idée du refactoring est en effet de réorganiser le code, ce qui peut prendre diverses formes selon les objectifs voulus. Ici, on parle d'un profiling, plus exactement d'un profiling avec des outils qui tendent à présenter leurs résultats par fonctions : telle fonction a pris tant de temps (avec ou sans ses appels à d'autres fonctions), telle fonction a été appelée tant de fois, telle fonction a appelé telle autre, etc.
Or, avec des outils qui imposent de travailler ainsi, tu te retrouves sans doute avec un rapport qui te dit que ta fonction principale a été appelé plusieurs fois et a pris telle quantité de temps en tout, telle quantité de temps en moyenne. Notre conseil serait donc de découper strictement ta fonction en plein de petites fonctions, courtes, lisibles, avec un nom reflétant leur tâche "métier" spécifique -- en faisant cela, tu obtiendras des rapports xdebug et des graphes kcachegrind exploitables car pointant directement quelles parties du traitement prennent le plus de temps.
Si elles ont du code en commun, tu dois pouvoir le déporter dans des fonctions communes de type "outil", elles-mêmes appelées depuis les fonctions métier. Et ça ne devrait pas trop gêner le profling puisqu'il est possible d'observer le temps "exclusive" (fonction uniquement) ou "inclusive" (fonction + ses appels d'autres fonctions) avec les outils mentionnés.

Ravi de voir que ça avance. 5000 requêtes en arrière-plan ? On parle bien de requêtes SQL ? Je ne voudrais pas te faire flipper, mais à 500 requêtes SQL pour une requête HTTP, on parle déjà de mastodonte...

Ok, j'ai regardé rapidement. Je pense qu'on est bel et bien dans l'optique d'un code qui fait le travail correctement mais qui le fait de manière trop naïve et tue les performances au passage. Première chose qui tue les performances : updateScore() ne traite qu'un joueur à la fois. Vu sa complexité et le type d'abstractions sur lesquelles tu t'appuies, ça n'est pas particulièrement étonnant, je ne vais donc pas insister sur la question.
updateScore() fait environ 300 lignes donc elle est un peu difficile à approcher. Je te conseillerais de refactorer la chose. Traditionnellement, on essaye de limiter la taille des fonctions à "un écran de hauteur" (~25 lignes traditionnellement... oui c'est vite limitant... tu peux compter 40, on survivra largement). Au-delà, on s'y noie à la relecture. Je note également que updateScore() a tendance à se rappeler elle-même pour effectuer diverses tâches subalternes... Ça ne pose pas de problème en soi vis-à-vis des performances (sauf si tu pars en boucle récursive infinie, ce qui serait carrément un bug), mais mon petit doigt me dit que tu vas le regretter lors de l'étape suivante :D

L'étape suivante, justement. Si je ne m'abuse, tu as pu tester ta solution initiale (avec l'anti-buffering) chez toi (ce que je vais appeler "localhost") ; j'en déduis que la soumission du formulaire ne tourne pas très vite chez toi non plus. Je t'invite donc à diagnostiquer sur localhost ce qui prend du temps dans l'exécution de submitForms.php (typiquement avec xdebug + kcachegrind, mais tu as le choix des armes), parce que, là, comme ça, en parcourant le tas de spaghetti, il m'est difficile de pointer un coupable particulier. Je dirais bien, au pif :
- l'accumulation des appels à find() à mesure que updateScore() se rappelle
- tu manipules des objets variés avec des liens entre eux -- je ne serais pas étonné que ProcessWire n'ait d'autre choix que de réécrire beaucoup d'enregistrements en base de données à la moindre modification.
Mais ce ne sont que des idées en l'air.
Tu voudras peut-être faire ça après le refactoring dans la mesure où analyser une fonction récursive avec xdebug+kcachegrind, c'est, hmm, comment dire, courageux ?

Voilà, voilà. Prends ton temps, je ne serai normalement pas dispo demain pour te conseiller.

Edit: j'oubliais : tous ces fichiers PHP/JS/HTML, tu les versionnes dans un coin avec SVN/GIt/whatever ?

celfred wrote:

Pour le coup, je suis prêt à concéder une certaine lourdeur pour le moment et je pense sincèrement que le problème ici vient davantage de moi que du CMS ! ProcessWire doit être capable de calculer rapidement tout ce que je souhaite et de gérer les requêtes SQL, mais moi je dois m'y prendre comme un manche...

Alors, justement, notre conseil, c'est pas vraiment de dropper le synchrone, au contraire. L'approche asynchrone avec batch JavaScript-driven, c'est un truc overkill, qui représente potentiellement beaucoup de boulot (dans la pratique, ça dépend, peut-être que ProcessWire peut te mâcher le travail, je ne sais pas, mais fais-nous juste confiance quand on te dit que c'est overkill) et qui ne réglerait pas le souci de base, à savoir que 30 secondes de temps CPU pour faire quelques SELECT, quelques additions (oui, je caricature) et claquer quelques requêtes UPDATE vers une base MySQL, c'est pas réglo, pas réglo du tout.
Concrètement, pointe-nous vers ton code qui fait le traitement en question et on se penchera dessus. (rappel : on est admins, on peut aller lire la chose ; on est juste trop fainéants pour se taper toute la lecture). L'idée, c'est de se pencher sur ce qui ne va pas de façon à ce qu'il n'y ait plus besoin de la moindre barre de progression.

Hello,

Tu veux modifier combien de valeurs, en gros ? Je suppose que ta question porte sur http://planetalert.tuxfamily.org/newsboard/ qui ne semble pas bien rapide pour le peu d'informations qu'il affiche.

Du coup, on peut te donner quelques tuyaux pour ta question de base :
- c'est assez suspect tes ob_get_contents(), ob_flush() sans un ob_start() de ta part ; en fait, je ne suis même pas sûr que tu aies vraiment besoin des fonctions ob_* pour parvenir à tes fins.
- le str_repeat(' ', 256) ne fonctionne probablement pas parce que la sortie de PHP est utilisée pour constituer une réponse HTTP qui est elle-même bufferisée par un serveur Apache puis par un serveur nginx... du coup, ton 256 est un peu faiblard, tu peux y aller à grands coups de 16384 pour outrepasser la plupart des configs par défaut... mais ton code restera susceptible de se retrouver coincé dans un buffer quelconque sur d'autres environnements.
- tu peux aussi t'amuser avec l'en-tête "X-Accel-Buffering" reconnu par nginx ( http://nginx.org/en/docs/http/ngx_http_ … _buffering ) mais là, encore, ça n'est pas une mesure efficace dans tous les cas.

Au-delà se posent les questions de la façon dont les navigateurs reçoivent les infos (par exemple, 16384 espaces, une fois gzippés en cours de route, ça n'a plus forcément le même effet) et du rythme auxquels ils les interprètent.
Globalement, quand un traitement est vraiment long, il est d'usage de l'exécuter de manière asynchrone ; chez TuxFamily, ça peut prendre la forme d'un cron job. Une autre approche consiste à découper le traitement en petits morceaux (des lots de 5 joueurs par exemple) et à exécuter chaque morceau, typiquement un par un, via des requêtes HTTP émises en JavaScript (plus connu sous le nom d'AJAX) ; avec cette approche, c'est du JavaScript côté client qui se charge de demander au serveur de faire un certain travail, d'attendre la réponse pour ce travail et en fonction de cette réponse (HTTP 200 vs HTTP 50x) mettre à jour un petite barre de progression).

Voilà pour répondre à ta question technique au sens strict du terme. Maintenant, notre ressenti, c'est que tu utilises un CMS en guise de couche d'abstraction, probablement pour éviter de toucher à certaines technos que tu ne maîtrises pas ou mal (au hasard : SQL ?), et que cette couche d'abstraction est en train de te poignarder dans le dos en termes de performance (et on ne te cache pas que c'est SUPER-COURANT). Du coup, nous t'invitons non pas à te prendre la tête avec des histoires de buffering, de batchs, de traitements asynchrones, etc. mais plutôt à attaquer le problème à la source.
Ainsi, tu mentionnes une erreur 50x au bout de 30 secondes. En l'état actuel des limitations en place chez TuxFamily, un processus PHP peut s'exécuter pendant beaucoup plus longtemps que ça avant de rencontrer les divers timeouts d'Apache et nginx... mais par contre, il n'est pas autorisé à "manger" plus de 30 secondes de temps CPU (comprendre 100% CPU pendant 30 secondes). Nous pensons que c'est cette limite que tu atteins, et que tu l'atteins pour modifier un petit nombre d'enregistrements, c-à-d un traitement qui devrait être plié en moins d'une seconde et ne devrait pas nécessiter ce chantier anti-buffering que tu as attaqué.
Si tu nous donnes plus de détails sur ce que tu veux effectuer et comment tu l'as implémenté, nous pourrons te conseiller.

46

(1 replies, posted in TuxFamily gaming)

Hi,

It depends on what you call "hosting a gaming project".
If you refer to hosting the official website, bugtracker, forums, screenshots, documentation, downloadable content of a free-licensed (as in freedom, not as in free beer) game, then yes, I'd say we do that quite often.
On the other hand, if you refer to the hosting of a specific server instance for multiplayer purposes, then things are a little different: we do host a few server instances, but the physical, underlying infrastructure is full, so we simply cannot accept an extra game server instance these days.

Y aurait-til une histoire de 'cache' pour le htaccess ? Je n'en sais rien du tout.

Nope : il n'y a absolument aucun mécanisme de cache pour les fichiers .htaccess.

Je te confirme qu'il nous est très difficile de diagnostiquer des problèmes que l'on ne peut pas reproduire et que l'on n'a jamais vus. Toutefois, les navigateurs déterminent s'ils doivent afficher un contenu ou le proposer pour téléchargement en se basant sur les en-têtes de la réponse HTTP, et plus particulièrement sur les en-têtes "Content-Type" et "Content-Disposition". Je t'invite donc à observer ces en-têtes lorsque tu reproduis le problème.

Il pourrait également être intéressant de t'intéresser aux éventuels caches de ton CMS car ceux-ci peuvent potentiellement nuire à la reproductibilité d'un bug.

Hello,

Commençons par le problème de base, à savoir le comportement en HTTP : je ne reproduis pas du tout le comportement annoncé ; je suppose que tu as travaillé dessus entretemps et que tu as résolu le problème -- tu confirmes ?

Hello,

Après diagnostic, il s'avère que Gmail nous contacte prioritairement en IPv6, sans fallback IPv4 en cas de time out.
Or, l'infrastructure pour les emails avait un souci IPv6, qui n'était pas très visible puisque les services restaient accessibles et fonctionnels en IPv4. Le souci IPv6 a été réparé et les choses devraient désormais rentrer dans l'ordre. Navré pour le dérangement, nous allons aviser pour que cela ne se reproduise pas.

Hello,

Oui, c'est possible, comme annoncé par notre news d'avril dernier.

La génération du certificat Let's Encrypt se fait automatiquement après la création de chaque espace web ; ainsi, un site comme, au hasard, gimpons.net, est d'ores et déjà accessible en HTTPS avec un certificat Let's Encrypt :

$ openssl s_client -connect www.gimpons.net:443 -servername www.gimpons.net:443 < /dev/null 2> /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -subject -issuer -dates
subject= /CN=gimpons.net
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
notBefore=Jul  5 22:25:00 2016 GMT
notAfter=Oct  3 22:25:00 2016 GMT

Charge ensuite au webmaster de s'assurer que les diverses ressources référencées par les pages HTML le soient via des URL en HTTPS ou via des PRURL pour satisfaire les exigences des navigateurs.