Gogs se présente effectivement comme plus sympathique en termes de performance et d'exploitabilité, mais les problématiques d'intégration sont a priori les mêmes :)

La page du script est déjà pré-remplie: nom de la db, utilisateur, mot de passe, host (sql) et j'ai rajouté le port Mysql  3306

Non, la page n'est PAS pré-remplie (sauf peut-être pour WordPress, la chose ayant une heuristique dédiée à ce CMS). Les champs texte contiennent par défaut des valeurs bidons à titre d'exemple, c'est tout. Tu dois donc tout fournir ;
- name : le nom de ta base de données chez TuxFamily
- user : chez TF, c'est la même valeur que le nom de la base de données
- password: le mot de passe pour accéder à ta db
- host : sql
- port : 3306 -- si tu laisses vide, il se débrouillera tout seul

Tu peux récupérer toutes ces infos dans librefan.eu.org/htdocs/sites/default/settings.php (ligne 215) -- FAIS GAFFE ! Il faut fournir le password sans échappement ; donc si tu as des choses genre \\, \$, \' ou \" dans ton settings.php, il faut enlever le premier backslash.

Il y a plusieurs aspects à traiter dans cette question. :)

Commençons par le besoin : "je ne veux pas aller sur Github (et ne me parlez pas de Sourceforge)" -- ça, ok.

"est-ce que je peux installer Gitlab, comme l'a fait Framasoft, et y mettre mon projet ?"
Je suppose que tu fais allusion à https://git.framasoft.org/ .
Si je prends la question stricto sensu : baaaah, euh, ouiii, bien sûr, tu peux prendre ton petit serveur, installer Gitlab dessus, et y mettre ton projet ;-)

Mais je suppose que la question serait plutôt : est-ce que tu peux installer Gitlab sur ton espace TuxFamily, de la même façon qu'un Drupal, WordPress ou whatever.
Techniquement, tu peux te lancer dans le chantier mais tu vas rapidement être déçue : le code Ruby de Gitlab doit pouvoir s'exécuter sur la plateforme web de TuxFamily (ça doit déjà être une belle aventure en termes de dépendances, de compilations, etc.), mais l'intérêt de la chose va tomber à l'eau lorsque tu vas t'apercevoir que Gitlab arrive à créer des dépôts mais pas à gérer qui peut y accéder over SSH.

Du coup, il reste à aborder le traditionnel "Est-ce que TuxFamily pourrait fournir une instance Gitlab à ses hébergés pour leur éviter l'installation d'un bugtracker PHP qu'on retrouvera troué jusqu'à la moelle trois ans plus tard ?".
On ne dit pas non, la question n'est pas nouvelle.
Concrètement, sans paraître infaisable, ça paraît délicat : comme tu le mentionnes toi-même, Gitlab a des fonctionnalités redondantes avec TuxFamily : on peut s'y inscrire, fonder des "groupes" (hey, comme chez nous !) et des "projets" (= des dépôts Git avec le tremblement qui va avec : tâches, jolis graphes pour savoir qui c'est qui glande le moins dans le projet, les petits avatars tout mignons, tout ça, tout ça...).
Du coup, techniquement, il faudrait intégrer cela à notre plateforme (VHFFS). Je ne sais pas si Gitlab est assez modulaire pour subir ce genre de "fusion" sans patch (j'en doute). Entre les utilisateurs, les groupes, les dépôts, les quotas, les demandes à la modération, le travail est non-négligeable.
Ergonomiquement, il y aurait clairement une redondance difficile à gérer : les hébergés se verraient proposer du Git à la fois dans le panel et dans l'interface de Gitlab.
Au-delà de ça, Gitlab est réputé gourmand en mémoire (donc il faudrait lui trouver une place dans l'architecture actuelle), et assez chiant en termes de dépendances (là, en Sid, le paquet "gitlab" indique 144 dépendances). Je passe sur la popularité de Ruby au sein de l'équipe...

Long story short : peut-être un jour, mais là, on n'est même pas certain de la faisabilité.

54

(6 replies, posted in Bistrot)

Quoi, il est tout seul à faire tout le boulot? mais que faisaient toutes ces  boullies un peu partout le 1er avril. Ils sont juste là pour boire des bières?

Ah, ça... Chacun sa spécialité... moi c'est manger des crêpes :]

55

(6 replies, posted in Bistrot)

Hello,

librefan wrote:

Vu poudreverte.org.[...] ce site a été très mal vu de la majorité de ceux qui écrivent des commentaires sur Linuxfr.org

C'est plutôt un compliment, ça :') Où sont donc ces commentaires déplacés ? Je n'ai trouvé aucun commentaire sur poudre verte sur https://linuxfr.org/news/les-temps-sont … family-org ...

librefan wrote:

Une bonne occasion de vous envoyer mille mercis pour tout ce que vous faites, pour votre compétence qui devrait faire rougir de honte disons à peu près toutes les entreprises spécialisées dans l'hébergement, et  pour votre dévouement à toute la «famille» et à GNU/Linux.

Merci, merci... mais tu n'es pas obligée de vouvoyer gradator tu sais :p

librefan wrote:

PS:
Une petite faute dans la phrase ci-dessous: ce devrait être “helps them achieve” (infinitif)
“TuxFamily takes  pride in providing  such people  with a  free  hosting platform  that helps  them achieving whatever good deed they are aiming for.”

Oui, en effet, mea culpa... Merci pour le feedback, ça m'a forcé à me pencher sur les règles exactes afférentes au verbe "help".

librefan wrote:

C'est presque tout clair, sauf qu'ils indiquent un port pour la DB mysql et je n'ai pas l'impression que chez TF on a besoin d'indiquer un port quelconque.

Chez TF, tu as l'habitude d'indiquer simplement "sql" mais en fait, dans le contexte d'un client MySQL, ça signifie par défaut "sql:3306" (donc hostname sql et le port par défaut pour le protocole MySQL : 3306).

librefan wrote:

Je ne savais pas du tout qu'il y avait un mouvement anti www.

Du coup savais-tu qu'il existait le mouvement opposé ? http://www.yes-www.org/

Et je vois aussi que tuxfamily.org n'a plus son www et redirige l'ancienne url vers tuxfamily.org

Normal, pour la plupart des gens qui ont des notions de DNS (ce qui est le cas chez Tuxfamily, je précise), le "www" c'est un non-sens historique bon à jeter.

librefan wrote:

drupal.org est passé à www.drupal.org

J'ai bien un avis sur la question, je peux l'exprimer très concisément mais pas poliment...

On parle donc ici de http://librefan.eu.org/ , c'est bien cela ?
Tu peux procéder aux remplacements dans ta base de données dès maintenant : lorsque ton site est accédé en HTTP, aucun navigateur ne refusera d'afficher des images et ressources en HTTPS.
Ensuite, tu peux ajuster la $base_url dans settings.php ; ton Drupal considérera alors que toutes les URLs absolues qu'il génère doivent commencer par cette $base_url et donc être en HTTPS.

Enfin, tu peux ajuster ton .htaccess. J'ai pris la liberté de jeter un coup d'œil à ton .htaccess ; précisons qu'il s'agit du même .htaccess qu'on peut trouver dans l'archive officielle drupal-7.43, avec pour seule modification pour le moment que tu as décommenté la directive "RewriteBase /".

Commençons par implémenter une redirection HTTP->HTTPS, càd une redirection effective uniquement en HTTP vers l'URL équivalente en HTTPS. Juste en-dessous de "RewriteEngine On", on ajoute :

# If the request comes over HTTP, enforce HTTPS through a 301 response:
RewriteCond %{HTTPS} !on
RewriteRule ^ https://librefan.eu.org%{REQUEST_URI}  [L,R=301]

On pourrait chipoter et générer une 307, théoriquement plus adaptée, mais la 301 a le mérite d'être vieille comme le monde, comprise de tous les navigateurs et de convenir dans 99.99...% des cas.

Enfin, pour forcer les gens à taper librefan.eu.org et non www.librefan.eu.org (rejoignant ainsi le mouvement http://no-www.org/ ), tu peux simplement décommenter les directives suivantes fournies par Drupal :

  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment the following:
  RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

Au-delà des manipulations que je viens de décrire, tu ne devrais pas avoir besoin de supprimer, modifier ou ajouter la moindre directive dans le .htaccess.

L'outil dont tu parles est pour WP.

Nan. Ça reste un outil générique, que tu peux utiliser avec Drupal comme avec n'importe quel base de données. Les dernières versions comportent des trucs en plus pour Drupal / Wordpress mais tu peux vivre sans. Et si je te conseille cet outil-là, c'est parce que je l'ai vu rendre de bons services sur des Drupals en milieu professionnel. Je te rejoins sur l'idée qu'un module Drupal pour modifier une base de données Drupal, c'est foireux.

Pour tuxfamily_repository, on l'avait écrit parce que le module "cdn" pour Drupal 7 ne faisait pas exactement l'affaire ; je ne sais pas si ça s'arrangera pour Drupal 8 (et sans vouloir faire mon oiseau de mauvaise augure, à ta place, je laisserais un peu d'eau couler sous les ponts avant de passer à D8).

Alors, quelques conseils pour le Drupal :

Concernant les remplacements en base de données :
On pourrait s'attendre à ce que la fonction "remplacer" de phpMyAdmin fasse l'affaire ; c'est d'ailleurs le cas pour certains setups simples (càd des Drupals jeunes, n'attendant que la première occasion pour devenir complexes :p) ; dans la pratique, l'extraordinaire tendance de la chose à stocker des données *sérialisées* dans sa base de données pousse à l'utilisation d'outils plus spécialisés tels que https://interconnectit.com/products/sea … databases/ , qui a le grand avantage de pouvoir gérer les remplacements dans des données sérialisées (sans devoir recourir à du vaudou de type "je dump, je claque un one-liner Perl tiré du dernier cercle de l'enfer sur le dump, je reload"). À noter que sa feature "dry-run" ne dispense PAS de faire une sauvegarde avant.

Concernant les URLs générées par l'application : il convient généralement d'ajuster $base_url dans settings.php ; deux écoles :
École #1 : mettre une $base_url en https, et implémenter via .htaccess la redirection qui va bien pour oublier complètement HTTP
École #2 : écrire un peu de code PHP dans le settings.php pour déterminer le protocole de la requête en cours de traitement et l'utiliser dans la base url.
Je ne sais pas si Drupal peut accepter une PRURL (une URL qui commence par // si tu préfères) en guise de $base_url... Je crois pouvoir affirmer que tu ne veux t'aventurer ni là-dedans ni dans la deuxième école...

Si par hasard, tu utilises le module tuxfamily_repository ( cf https://faq.tuxfamily.org/WebArea/Compat/Drupal7/Fr ) : tu voudras modifier, dans les options avancées du module, le paramètre "Base URL of your TuxFamily repository" ou alors tu peux claquer directement dans ton settings.php:

$conf['tuxfamily_repository_base_url_pattern'] = 'https://download.tuxfamily.org/@project/@path';
librefan wrote:

mais j'obtiens la même erreur:

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''http://librezele.fr.cr''//librezele.fr.cr') FROM wp_posts WHERE' at line 1

Il semblerait tout simplement que tu aies oublié de saisir la virgule entre le deuxième et le troisième argument de ton appel à la fonction REPLACE.

Hello,

Il n'est pas exclu qu'une extension dans le navigateur pose problème, mais ça me semble tout de même assez capilotracté compte tenu de la simplicité de notre certificat. La prochaine fois que tu rencontres ce problème, tu peux déterminer si ton navigateur est innocent en lançant la commande suivante :

echo '' | openssl s_client -connect web.tuxfamily.net:443

Si elle te crache un "Connection refused", ton navigateur est innocent ; si elle te crache une cinquantaine de lignes incluant "Server certificate", tes extensions posent peut-être problème.

62

(14 replies, posted in Suggestions)

Hello,

Petit résumé de la situation :
- Let's encrypt émerge, en effet ; il semble être passé de vaporware (ça n'existe pas) à fancyware (c'est mignon, mais ça ne fait pas de miracle).
- TuxFamily devrait se pencher sur les impacts de la limitation à 90 jours des certificats émis par Let's encrypt.
- Idéalement, TuxFamily pourrait faire bénéficier tous ses sites *.tuxfamily.org d'un certificat TLS valide... si Let's encrypt daignait supporter la chose, ce qui n'est bien sûr pas le cas... https://community.letsencrypt.org/t/ple … icates/258
- En faire bénéficier TOUS les hébergés (*.tuxfamily.org + domaines persos) requière des développements spécifiques (upload et stockage des certificats, accès par les webservers, sécurité). Avec un peu de chance, TuxFamily pourrait piocher dans des développements tiers.

En résumé, Let's Encrypt pour TuxFamily, ça n'est pas encore pour tout de suite.

Hello,

Comme pour beaucoup de problèmes se produisant "de temps en temps", il faut d'abord s'assurer de son existence, le reproduire puis le diagnostiquer... Pourrais-tu passer nous voir sur notre canal IRC la prochaine fois que le problème se produit ? Nous pourrons alors regarder au plus vite.

Hello,

Merci pour ce feedback. Les corrections correspondantes ont été appliquées dans la branche de développement de VHFFS, le moteur sur lequel repose TuxFamily. Ces typos disparaîtront lors de la prochaine mise à jour de VHFFS sur nos infrastructures.

65

(3 replies, posted in Remerciements)

You're welcome :)

66

(7 replies, posted in Suggestions)

Hello viktor,

Oui, on avait vu les news... ça nous incite effectivement à revoir nos fondations techniques. L'équipe est d'ailleurs partagée sur cette nouvelle approche :

  • d'un côté, chiffrer toutes les connexions HTTP, c'est bien, ça limite les risques d'interception et de falsification, et en plus, on n'aura plus jamais d'ennuis avec les sites mixtes HTTP+HTTPS

  • d'un autre côté, en l'état actuel du marché des certifs-X509-qui-juste-marchent-partout (à une date où l'initiative Let's Encrypt n'est encore que du vaporware), cette initiative constitue une élévation du prix à payer pour mettre son petit bout de texte sur Internet ; celui qui ne veut rien débourser ou ne pas dépendre de l'aval des autorités de certification finira avec un ersatz de "feu orange" à gauche de l'URL de son site -- on peut aussi s'inquiéter:

    • que l'initiative provienne d'un projet lié à Google (qui vont se faire une joie d'ajuster leur panel de services en conséquence)

    • qu'elle constitue une source de revenus supplémentaires pour les actuelles autorités de certification

    • et qu'elle augmente le pouvoir de ces mêmes autorités via leurs CRL.

Bref, on va voir ce qu'on peut faire pour se préparer à ça... avec un peu de chances, une partie du chemin sera déblayée par d'autres hébergeurs/contributeurs...

Edit: oh, j'oubliais :

Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.

Salut,

Bon, sans même jeter un coup d'oeil à ta base de données, tâchons d'éclaircir la situation...

D'après l'équipe de Drupal il suffit de supprimer index.php pour que le site soit à l'abri.

C'est une drôle de recommandation, sachant que le patch pour cette vulnérabilité est assez trivial (un patch à appliquer ou, pour ceux qui ne savent pas, une seule ligne de code à changer)...

donc j'ai eu un intrus qui a pu se mettre en utilisateur forouq avec pas mal de droits.

"forouq" ? C'est le nom de ton utilisateur administrateur (uid 1) ?

J'ai fait la mise à jour et les attaques continuent naturellement. Je ne suis pas assez calée pour savoir si les attaques échouent vraiment ou si elles peuvent aboutir.

Les attaques continuent ? Comment ça ? Qu'observes-tu ? Qu'appelles-tu "attaques" ? La faille en question est une injection SQL -- c'est rapidement exploitable mais une fois corrigé, c'est corrigé... par contre, les attaquants ont pu créer plusieurs comptes privilégiés pour revenir, auquel cas une bonne séance de ménage s'impose (du côté des utilisateurs Drupal, des modules en place, des views configurées mais également du côté du filesystem, au cas où une backdoor y trainerait...).

Si tu ne penses pas avoir les compétences nécessaires pour effectuer un tel ménage, tu peux effectivement partir sur l'optique d'une simple restauration.
Comme longuement détaillé sur notre FAQ, nos sauvegardes ne nous permettent pas de te fournir une backup antérieure au 15/Oct (date de l'annonce officielle), tu ne peux donc te baser que sur tes archives. Tu peux demander une nouvelle base de données si ça peut te faciliter la vie, nous ne refuserons pas. Nous te conseillons tout de même de garder une sauvegarde de ta base actuelle au cas où tu voudrais y repiquer des informations un jour.

Hmm, il va falloir expliciter ce passage de la FAQ en remplaçant "vous" par "vos applications web" :

Copier des fichiers vers les espaces de téléchargements

    Vos applications web peuvent accéder aux espaces de téléchargements à partir des serveurs web via le répertoire /data/repository, par exemple /data/repository/vhffs4 pour le groupe vhffs4.

    Attention, vos applications ne doivent pas faire des accès fréquents en lecture vers ce répertoire ; celui-ci doit seulement être utilisé pour envoyer des fichiers du service web vers l'espace de téléchargement. Vos applications ne doivent pas lire des fichiers sur ces espaces et encore moins lister le contenu des répertoires. En gros gardez un index des fichiers uploadés de votre côté et fournissez des URLs du type http://download.tuxfamily.org/.../ à vos visiteurs.

Voilà. Bon, c'est rédigé un peu sévèrement : il est possible d'effectuer ces opérations mais avec parcimonie ; cela est dû au fait que la manipulation des fichiers des espaces de téléchargement s'effectue over NFS vers un serveur autre que notre filer principal et en termes de performances il ne faut pas en abuser. De plus, nos download repositories implémentent le principe de CDN : l'intérêt n'est pas d'avoir 11 fois plus de place en une seule demande VHFFS mais d'avoir un moyen de distribuer efficacement des fichiers statiques sans charger l'archi qui exécute les applis web.

Hello,

Indeed, there are currently no plan to change the path you used -- it's computed, you know: the digits are taken from the MD5 hash of your webarea ( try echo -n recaged.net | md5sum in your shell)
Regarding your .htaccess, have you tried with %{ENV:DOCUMENT_ROOT_HASH} instead of %{DOCUMENT_ROOT_HASH}?

librefan wrote:

J'ai donc mis comme upload_url_path http://localhost/files

Ok, il s'agit bien là de la base URL par laquelle tes fichiers seront accessibles.

librefan wrote:

et comme upload_path files

Je pense que ce n'est pas bon. Tu indiques un chemin relatif ("files")... au DocumentRoot de ton serveur web, ce dont WordPress se fiche (il veut juste savoir dans quel dossier local planquer ses fichiers) ; il faudrait donc quelque chose comme /home/librefan/htdocs/files.

librefan wrote:

Mais  l'upload_path doit être faux, car pouf et files sont tous deux à la racine. Je crois que j'aurais dû mettre ..files pour remonter d'un niveau.

"../files", oui, car WordPress va sans doute traiter les chemins relatifs par rapport au dossier parent des scripts faisant office de point d'entrée pour les requêtes dynamiques, ici /home/librefan/htdocs/pouf.

En fait, WP a fait un nouveau dossier files dans pouf et c'est là qu'est l'image.

... ce qui confirme l'hypothèse : les chemins relatifs sont interprétés par rapport au dossier contenant l'application.

Chez Tuxfamily, les 2 valeurs devraient être (en regardant sur un de  mes sites TF): [snip]

upload_url_path: http://download.tuxfamily.org/mon_projet/files
upload_path: /data/repository/mon_projet/files
... comme indiqué par la doc. GFTP te montre en fait une arborescence virtuelle, légèrement différente selon le protocole (FTP vs SFTP/SSH) qui ne reflète pas forcément les arborescences disponibles sur nos serveurs web (et c'est ça qui compte pour que ton site web fonctionne).

Hmm, on ne peut pas vraiment se permettre d'avoir une FAQ non lisible -- pourrais-tu essayer avec un autre navigateur ou nous donner plus de détails techniques (idéalement suivre ce qui se passe avec Firebug et son onglet réseau) ?

Sinon voici le contenu de la page en question :

Wordpress permet nativement de déporter le dossier d'upload. Pour cela, il suffit de remplir les deux champs Store uploads in this folder et Full URL path to files dans Settings → Media.

    Store uploads in this folder: chemin local où WordPress va enregistrer les fichiers. Il faut qu'il soit accessible par PHP avec des droits appropriés. En pratique, il faut le définir à quelque chose comme /data/repository/<nom du groupe>/.../ (voir WebArea/Fr#Copier des fichiers vers les espaces de téléchargements).
    Full URL path to files : base d'URL fournie aux visiteurs. C'est le début de l'URL que WordPress utilisera pour afficher les médias. En pratique, il faut qu'elle pointe vers http://download.tuxfamily.org/<nom du groupe>/.../, comme indiqué dans la doc générique


Pour WordPress 3.5

Dans WordPress 3.5 les options ont disparues de la page. Cependant, il est possible avec quelques efforts non seulement de s'en passer, mais aussi de les faire réapparaître.

Pour se faire, il va falloir modifier la base de données à la main. Connectez-vous à votre base de données WordPress (par exemple via PphMyAdmin, voir DbMySQL/Fr), et sélectionnez la table wp_options. Trouvez les champs upload_path (ID 54 sur mon installation fraîche) et upload_url_path (ID 61 sur mon installation), qui correspondent respectivement au chemin local et à l'URL décrits plus haut.

Remplissez ces champs avec les valeurs appropriées comme expliqué plus haut. Une fois les champs remplis, les deux options appariassent et dans la page de configuration Settings → Media et fonctionnent comme dans les anciennes versions.


Sources

    http://www.ampercent.com/wordpress-stor … omain/908/
    http://programepc.net/media-image-in-su … press-3-5/

Hello,

Commençons par le problème de base : qu'obtiens-tu comme contenu/erreur en visitant http://faq.tuxfamily.org/WebArea/Compat/Wordpress/Fr ?

Salut,

magicvinni wrote:

J'ai essayé comme un grand de faire un apt-get install python-sympy mais sans succès. A-t-on les droits pour le faire

Absolument pas : nous fournissons une infrastructure mutualisée, pas des machines dédiées.

magicvinni wrote:

si non, pouvez-vous mettre à jour ce module.

Hélas non. Notre politique là-dessus est assez simple : nous voulons bien installer des modules complémentaires pour aider au bon fonctionnement des diverses applications de nos hébergés, mais nous nous cantonnons à ce qui est packagé et maintenu dans les dépôts Debian stable (pour des raisons de sécurité et de maintenabilité). Or, en l'état actuel de Debian stable, python-sympy ne va pas au-delà de la 0.6.7.
En revanche, tu peux toujours mettre en place la version de ton choix de ce module dans ta zone web (typiquement dans le mal-nommé "php-include") et jouer sur la valeur de sys.path pour l'utiliser en lieu et place de celle fournie par le système. Bien entendu, tu hérites de la responsabilité de mettre à jour ce module en cas de problème de sécurité connu.

Your project was finally accepted. You will now have to require additional services such as web areas, databases, etc. Please refer to our FAQ in case you have a technical question: http://faq.tuxfamily.org/

Trac can be installed since our web architecture enables you to execute CGI-compatible Python programs; since you are not the first one trying to install Trac, you should normally find any Python dependency required for a standard Trac installation. Importing existing data should not be a problem at all.

Hi again Daniel,

I guess your project can be hosted at TuxFamily's then -- please post again its description along with its license using our panel and it should be accepted pretty quickly.