Après inspection : tu pourrais gagner de l'espace en déportant tes uploads WordPress dans un espace de téléchargement (cf notre FAQ, on a une page sur le sujet).
Mais bon, en attendant, j'ai augmenté ton quota à 500... enjoy :)

Hello,

Le quota actuel de ton projet est de 366/400 Mio.
Je vais supposer que cela inclut les 17 Mio de wordpress-5.8.3.zip, mais pas les 61 Mio que l'on obtient quand on décompresse wordpress-5.8.3.zip... ton quota semble insuffisant pour faire cette mise à jour.
Je vérifie le contenu de ton espace web et j'avise.

isaacpony wrote:

J'ai donné les autorisations (777) à tous les fichiers et dossiers qui se trouvent dans le répertoire vendor

Ah, j'oubliais : c'est mal. Très mal.
Voir le premier point de https://faq.tuxfamily.org/Security/En#Advice / https://faq.tuxfamily.org/Security/Fr#Conseils

"does not appear to be a file nor a folder", "could not delete"... ça sent le souci induit par notre filesystem virtuel.

Applique la partie "/tmp/dest" expliquée sur https://faq.tuxfamily.org/WebArea/Compat/Composer/En :

export COMPOSER_HOME=/home/lapluma/tools/composer
export XDG_CACHE_HOME=/home/lapluma/cache
export COMPOSER_VENDOR_DIR=/tmp/lapluma-vendor
mkdir -p "${COMPOSER_HOME}" "${XDG_CACHE_HOME}" "${COMPOSER_VENDOR_DIR}"
chgrp lapluma "${COMPOSER_VENDOR_DIR}"
chmod +s "${COMPOSER_VENDOR_DIR}"
~/lapluma/tools/composer/composer.phar install

Je pense qu'il va falloir mettre à jour la FAQ sur ce sujet.

Avant, composer utilisait $COMPOSER_HOME/cache ; apparemment, ça a changé et il utilise désormais ~/.cache, avec une vague tentative de respecter les variables d'environnement XDG :

composer $ grep '\.cache' src/Composer/Factory.php
$xdgCache = getenv('XDG_CACHE_HOME') ?: $userDir . '/.cache';

Du coup essaye ça :

export COMPOSER_HOME=/home/myprojectgroup/tools/composer
mkdir -p "${COMPOSER_HOME}"
export XDG_CACHE_HOME=/home/myprojectgroup/cache
mkdir -p "${XDG_CACHE_HOME}"
composer ...

Oh, et supprime le contenu de /home/.cache, bien entendu.

6

(1 replies, posted in Help for TF users)

Hi,

Indeed, we do not provide Composer itself. We could provide it but it would come from stable/oldstable Debian packages. Things would work fine at first then, as time goes on, more and more would report this version is too old because of this bug here or that feature there, etc.
In the end, it is probably simpler and more reliable to follow https://getcomposer.org/download/ -- feel free to adjust the FAQ (yes, you can) to reflect that if you feel this is needed.

Eh bien, oui, il s'agit peut-être d'un souci induit par l'architecture TuxFamily : en effet, si je déporte le dossier de destination des paquets vers /tmp:

mkdir /tmp/dest
chgrp arcenterre1 /tmp/dest
chmod +s /tmp/dest
COMPOSER_VENDOR_DIR=/tmp/dest ~/arcenterre1/tools/composer/composer.phar install
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Package operations: 26 installs, 0 updates, 0 removals
  - Installing bcosca/fatfree (3.7.1): Extracting archive
  - Installing doctrine/lexer (1.2.0): Extracting archive
  - Installing ezyang/htmlpurifier (v4.12.0): Extracting archive
  - Installing psr/container (1.0.0): Extracting archive
  - Installing symfony/service-contracts (v2.0.1): Extracting archive
  - Installing symfony/stopwatch (v5.0.2): Extracting archive
  - Installing symfony/process (v5.0.2): Extracting archive
  - Installing symfony/polyfill-php72 (v1.13.1): Extracting archive
  - Installing paragonie/random_compat (v9.99.99): Extracting archive
  - Installing symfony/polyfill-php70 (v1.13.1): Extracting archive
  - Installing symfony/options-resolver (v5.0.2): Extracting archive
  - Installing symfony/finder (v5.0.2): Extracting archive
  - Installing symfony/polyfill-ctype (v1.13.1): Extracting archive
  - Installing symfony/filesystem (v5.0.2): Extracting archive
  - Installing psr/event-dispatcher (1.0.0): Extracting archive
  - Installing symfony/event-dispatcher-contracts (v2.0.1): Extracting archive
  - Installing symfony/event-dispatcher (v5.0.2): Extracting archive
  - Installing symfony/polyfill-php73 (v1.13.1): Extracting archive
  - Installing symfony/polyfill-mbstring (v1.13.1): Extracting archive
  - Installing symfony/console (v5.0.2): Extracting archive
  - Installing php-cs-fixer/diff (v1.3.0): Extracting archive
  - Installing doctrine/annotations (v1.8.0): Extracting archive
  - Installing psr/log (1.1.2): Extracting archive
  - Installing composer/xdebug-handler (1.4.0): Extracting archive
  - Installing composer/semver (1.5.0): Extracting archive
  - Installing friendsofphp/php-cs-fixer (v2.16.1): Extracting archive
Generating autoload files
htdocs/pretty$ ls -al /tmp/dest/
total 356
drwsr-sr-x   12 arcenterre arcenterre1   4096 Jun 29 19:57 .
drwxrwxrwt 9396 root       root        311296 Jun 29 19:57 ..
-rw-r--r--    1 arcenterre arcenterre1    178 Jun 29 19:57 autoload.php
drwxr-sr-x    3 arcenterre arcenterre1   4096 Jun 29 19:57 bcosca
drwxr-sr-x    2 arcenterre arcenterre1   4096 Jun 29 19:57 bin
drwxr-sr-x    4 arcenterre arcenterre1   4096 Jun 29 19:57 composer
drwxr-sr-x    4 arcenterre arcenterre1   4096 Jun 29 19:57 doctrine
drwxr-sr-x    3 arcenterre arcenterre1   4096 Jun 29 19:57 ezyang
drwxr-sr-x    3 arcenterre arcenterre1   4096 Jun 29 19:57 friendsofphp
drwxr-sr-x    3 arcenterre arcenterre1   4096 Jun 29 19:57 paragonie
drwxr-sr-x    3 arcenterre arcenterre1   4096 Jun 29 19:57 php-cs-fixer
drwxr-sr-x    5 arcenterre arcenterre1   4096 Jun 29 19:57 psr
drwxr-sr-x   16 arcenterre arcenterre1   4096 Jun 29 19:57 symfony

À la lecture de https://getcomposer.org/doc/03-cli.md#c … untime-env , je soupçonne Composer de faire des choses un peu spéciales pour aller toujours plus vite, butant ainsi sur une subtilité indéfinie de vhffsfs, notre filesystem virtuel utilisé pour les manipulations en SSH. À creuser.
En attendant, il doit suffire de déplacer le contenu de /tmp/dest dans le dossier pretty/vendor (ce que j'ai fait).
Et de fait, https://arcenterre.tuxfamily.org/pretty/signIn reflète désormais mieux qu'une page vide.

Hello,

J'ai pu reproduire ton souci. Ton installation de composer semble correcte. Il ne semble pas s'agir d'un problème de droits (j'ai d'ailleurs rétabli les permissions). Il est encore trop tôt pour dire si l'architecture de TuxFamily est responsable de ce souci.
Les installations échouent également avec --no-dev, qui réduit le nombre de paquets à installer à... deux. Idem en enlevant la variable d'environnement COMPOSER_HOME.
Même en -vvv, composer ne semble pas disposé à dire pourquoi les installations échouent.
Je ne compte pas autant de commandes en "exit 1" que de failed, j'en déduis que les commandes exécutées ne sont pas le cœur du souci. Par contre, il y a effectivement pas mal de rmdir() qui terminent en ENOTEMPTY, ce qui me fait songer à un problème de chemin.
Je continue de creuser le sujet...

9

(4 replies, posted in Help for TF users)

kdadmin wrote:

If that is the fix, where do I place this .htaccess file?

Typically in the same directory as your phpBB/pubBB installation.

kdadmin wrote:

I cannot find an existing one anywhere.

How do you list files? Most PHP software come with a .htaccess file, typically filled with various RewriteRules. However, filenames that start with a dot are considered hidden files and may not be displayed unless explicitly requested.

kdadmin wrote:

And is it simply a file named .htaccess with the single line: "AddType application/x-httpd-php7 .php"  ?

Absolutely. *.htaccess files are not specific to TuxFamily (they are specific to the Apache web server though); there is plenty of documentation on the Internet about them.

kdadmin wrote:

Loggins are unsecure.
Is there a fix for this?

As I am writing this message, both https://forum.dslav.tuxfamily.org/ and https://dslav.tuxfamily.org/ are considered secure. The fix was to... wait for the morning. Explanation: TLS/X.509 certificates are not requested immediately, so there is a one-day delay during which your freshly spawned web area is not considered secure over HTTPS.

10

(2 replies, posted in Suggestions)

Hello,

Juste sur le serveur SSH, je suppose ? Si oui, c'est fait.

Je vois que j'arrive un peu tard. TuxFamily propose effectivement PHP 7, moyennant une petite manipulation supplémentaire (décrite dans notre FAQ). Par contre, ça n'explique pas que ton WordPress soit "tombé" du jour au lendemain. Aurait-il par hasard un mécanisme de mise à jour automatique de ses extensions ?

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

13

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

20

(2 replies, posted in Suggestions)

Hello,

Pour faire simple : absolument aucun plan dans cette direction.

21

(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

22

(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

23

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