Hello,

Niveau DNS, tout semble fonctionnel :

$ host -t NS roem.site
roem.site name server ns1.tuxfamily.net.
roem.site name server ns2.tuxfamily.net.
$ host roem.site
roem.site has address 212.85.158.4
roem.site has IPv6 address 2a02:2178:1000:201::4
roem.site mail is handled by 20 mx2.tuxfamily.net.
roem.site mail is handled by 10 mx1.tuxfamily.net.

Par contre, tu n'as aucun espace web correspond à "roem.site". Je t'invite à consulter la page "MigrationDomainName" de notre FAQ : https://faq.tuxfamily.org/MigrationDomainName/Fr

2

(3 replies, posted in Suggestions)

Hello,

C'est installé :)

Hello,

Le service MySQL n'écoute qu'en interne.
Cela dit, il est possible de faire un tunnel SSH:
ssh -L127.0.0.1:3306:sql:3306 ton_user@ssh.tuxfamily.org

À noter que si ton but est de faire des sauvegardes, alors il est probablement plus simple et plus performant de récolter le dump MySQL que nous générons quotidiennement.

Hello,

Tu veux dire le site fr.flightgear.org je suppose ?
Très vraisemblablement, tu essayes de supprimer un fichier dans un répertoire qui ne possède pas les bonnes permissions Unix (chmod g+w)... ça tombe bien, il n'y en a qu'un : htdocs/forums_sup/addon, et il contient justement un fichier index.html. J'ai pris la liberté de corriger les permissions, tu peux réessayer.

Hello,

Au hasard : problème de quota disque ? En même temps, rien que les DB GeoLite2, ça te mange plus d'un quart de ton quota :)
Bwalé, +200M parce que ton projet est sympa :)

eadwardus wrote:

In my case i mean expanding the url to another one, i'm hosting the files in another server, but i wanted to use my domain, so would be something like:
call: downloads.mydomain/dir/file -> downloads.anothersite/dir/file

In this case is it possible to do without asking for another web space? (only with the DNS)

First things first: DNS only deals with domains, not full HTTP URLs.
So, in your case... well, it depends. In your example, the HTTP request URI is left untouched (/dir/file remains /dir/file) so you could handle this with DNS only if (and only if) the target web server (downloads.anothersite) correctly handles HTTP requests bearing this header: "Host: downloads.mydomain". And if you want HTTPS (who doesn't nowadays?) then the target web server should also have the adequate certificate to handle requests for downloads.mydomain.

Assuming all of this failed, the best way to proceed consists in:

  • Handling the "mydomain" DNS domain somewhere (e.g. at TuxFamily's)

  • Creating the "downloads" subdomain and making it point to TuxFamily's web servers: a CNAME to web.tuxfamily.org will do

  • Creating the "downloads.mydomain" web area

  • Generating the adequate HTTP redirects through this web area, typically using a .htaccess file

eadwardus wrote:

It's a repository of packages, all of them are open source, but i will only redistribute them in binary form

That should be okay.

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 ?

9

(2 replies, posted in Suggestions)

Hello,

Pour faire simple : absolument aucun plan dans cette direction.

10

(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

11

(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

12

(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.

19

(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).

21

(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.