Hello,

Ajoute ceci dans ta configuration SSH (~/.ssh/config) :

Host *.tuxfamily.org
    HostKeyAlgorithms +ssh-rsa

Hi and welcome!

- Yes, you should request exult.info. You can test it by adding an entry to your /etc/hosts file, e.g. 212.85.158.4 exult.info to make your browser believe exult.info already points at TuxFamily.

- Technically, you can leverage your TuxFamily SSH access to update your files any way you want... but in practice, giving your TuxFamily SSH access to a third-party sounds quite dangerous. Fiddling with a separate user and Unix permissions is possible but remains error-prone. I see two main approaches: a TuxFamily cron job that regularly checks whether it should rebuild your site, or a custom web page with authentication to reproduce that upload-unzip-done mechanism you described.

- I confirm installing phpBB should work. Just beware of spam.

- once your web area is created, you can use it. The TLS certificate is created and installed automagically, BUT it happens at night, so your web area will be TLS-less for the first day of its life.

By the way, most questions about TuxFamily have their answers on our FAQ, e.g. https://faq.tuxfamily.org/WebArea/En#Ho … 2FHTTPS.3F -- feel free to have a look (and you can even improve it if you want).

3

(3 replies, posted in Entraide dev)

Hello,

Plusieurs approches :
L'approche de base est effectivement d'utiliser git sparse-checkout, qui a justement été introduit pour ce cas de figure (qui doit bien être la seule régression lors du passage de SVN à Git).

Une deuxième approche consiste à bouger les éléments dans leur propre repo Git, et à déclarer ce nouveau repo comme submodule du repo de l'application.
Inconvénient : impact sur le workflow des développeurs, packageurs et beta-testeurs.
Avantage : approche plus clean / plus pro -- bon, c'est un peu subjectif, j'en conviens.

Une troisième approche consiste à penser "cache" : de mémoire, le dépôt d'éléments a un cache pour ne pas se retaper la conversion QET->SVG à chaque fois. Il serait donc possible d'employer une machine tierce pour générer directement ce cache (SVG+meta) et le pousser régulièrement chez TuxFamily. Il n'y aurait alors que la partie "upload" du dépôt qui convertirait des éléments QET en SVG, le reste serait statique.
Inconvénient : implique d'avoir une machine supplémentaire capable de convertir un QET en SVG.
Avantage : la machine supplémentaire ne serait pas cantonnée à PHP, elle pourrait refiler le rendu SVG à un utilitaire C++/Qt lié à QET.

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.

9

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

12

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

13

(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

16

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

23

(2 replies, posted in Suggestions)

Hello,

Pour faire simple : absolument aucun plan dans cette direction.

24

(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

25

(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