Search options (Page 3 of 5)

Hi Michael,

Thanks for your kind feedback, it is always heartwarming to read such thanks :)

Pas nécessairement. HTTP n'est pas encore complètement mort. Notamment, la simplicité de ce protocole comparé à HTTPS fait qu'on peut imaginer que certains projets souhaitent que leurs ressources restent accessibles over HTTP pour s'éviter une palanquée de bugs à base de "sur tel système, le téléchargeur claque telle erreur SSL".

Oui, ce serait à nous de le faire. Et nous le ferons sans doute un jour.

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 :)

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

Hello,

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

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

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

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.

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';

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.

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.

You're welcome :)

Salut,

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

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

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

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.

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