Classement

Bonjour, j'ai pas trouvé de documentation explicite pour installer Wallabag en environnement mutualisé alors voici la procédure que j'ai utilisée grâce aux conseils de Benoit - Merci à Lui Wallabag utilise composer pour s'installer et configurer le site et la base de donnée. c'est donc un prérequis a déployer pour commencer. Étape 1 : Installation de composer Voici une procédure pour utiliser composer et phar avec votre hébergement. Récupérer son php.ini depuis l'interface manager iWal (dans Domaines web > "Voir le php.ini") et le copier sur votre système de fichier en SSH Connectez-vous en SSH et editer un nouveau fichier php.ini taper à la racine de votre hébergement par exemple cd /datas/volX/w4aXXXXXX/var/www/Modules vi php.ini et copier le contenu récupéré dans le php.ini du manager IWal. 3. Ensuite à chaque ligne de commande vous devez indiquer votre fichier php.ini en paramètre Suivant votre version de php que vous souhaitez utiliser vous devez utiliser les commandes suivantes: php -c /chemin_php_ini/php.ini (ver7) php53 -c /chemin_php_ini/php.ini php54 -c /chemin_php_ini/php.ini php55 -c /chemin_php_ini/php.ini php56 -c /chemin_php_ini/php.ini 4/ vérifier que tout fonctionne avant d'installer composer php -c /chemin_php_ini/php.ini -i | grep version ou php -c /chemin_php_ini/php.ini -r 'echo phpversion();' 2>/dev/null 5 / Installer composer vous pouvez installer composer en modifiant le répertoire d'installation pour mettre un dossier de votre pack d'hébergement MAIS en dehors d'un site accessible via http Voici le détail pour l'installation adapté des commandes du site suivant : https://getcomposer.org/download/ (le checksum sera a adapter en fonction de la version de composer) php -c /datas/volX/w4aXXXXXX/var/www/Modules/php.ini -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" php -c /datas/volX/w4aXXXXXX/var/www/Modules/php.ini -r "if (hash_file('SHA384', 'composer-setup.php') === '544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdfdd586475ca9813a858088ffbc1f233e9b180f061') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" php -c /datas/volX/w4aXXXXXX/var/www/Modules/php.ini composer-setup.php php -c /datas/volX/w4aXXXXXX/var/www/Modules/php.ini -r "unlink('composer-setup.php');" Vous pourrez ensuite utiliser composer via son dossier d'installation. Dans votre session SSH vous pourrez également créer un alias "composer" est mettre /votre/dossier/installation/composer/composer.phar alias composer="/datas/volX/w4aXXXXXX/var/www/Modules/composer/composer.phar" Étape 2 : On lance l'installation de Wallabag après avoir créé un domaine web dédié à wallabag ainsi qu'une base de donnée mysql on se place en ssh dans le dossier du domaine web Je télécharge et extrait le logiciel wget https://wllbg.org/latest-v2-package && tar xvf latest-v2-package Je supprime le package d'installation rm latest-v2-package Je remonte les fichier d'un répertoire pour les mettre a la racine du site cd wallabag-release-2.3.2/ mv * ../ j'initie l'installation de composer pour wallabag php -c /datas/volX/w4aXXXXXX/var/www/Modules/php.ini /datas/volX/w4aXXXXXX/var/www/Modules/composer/composer.phar install j'édite le fichier app/config/parameter.yml avec les bonnes informations notamment la base de données et l'url du site Enfin je lance l'installation de wallabag en ligne de commande. php -c /datas/volX/w4aXXXXXX/var/www/Modules/php.ini bin/console wallabag:install Voilà en espérant que ça puisse aider certains d'entre vous

Ok pour tous mes comptes sur mon smartphones. Merci

cela fonctionne avec outlook donc c'est bon signe Je testerai le reste début de semaine prochaine Merci

Je vais essayer oui

Je vois, ça confirme pourquoi je n'ai jamais réussi à paramétrer une URL facebook dans le DNS malgré mes multiples tentatives. Mais sans aller jusqu'à laisser la possibilité au gens de remplacer totalement l'url facebook par leur propre nom de domaine, ils pourraient au moins autoriser une simple redirection vers leur page facebook, ainsi on ne spolie pas l'identité de FB, c'est bien l'URL FB qui s'affiche... Merci à toi

Tu ne peux pas faire pointer un nom de domaine à toi sur une page Facebook, ils ne permettent pas ce genre de chose, et ne gèrent pas les noms de domaines externes. Ce que tu peux faire en revanche, c'est effectuer une redirection web de ton domaine vers ta page FB, mais dans ce cas ton domaine n'apparaîtra plus dans la barre d'adresse après redirection. Ou bien inclure la page FB dans une iframe (je ne sais pas si FB le prévoit dans leurs ToS ?...)

Super nouvelle 🙂 si vous avez besoin d’un bêta testeur, je suis volontaire

Bonjour, Ce n'est pas une question, mais plutôt une réponse :-). Le lecteur RSS tt-rss a besoin d'un démon ou d'une tâche planifiée pour mettre à jour les flux RSS. Maintenant que Yulpa gère les tâches planifiées, on peut avoir un tt-rss bien configuré. Quelques subtilités, donc je partage mes trouvailles pour les configurer : Les tâches planifiées sont dans la sous-section « Fichiers & Accès -> Tâches planifiées ». Malheureusement, tt-rss demande d'exécuter la commande php update.php --feeds et les tâches de Yulpa ne prennent pas d'arguments, donc on ne sait pas où mettre le --feeds. Solution : créer un autre script PHP qui va appeler update.php correctement. Là, php va râler que les modules MySQL, JSON, mbstring et DOM ne sont pas actifs. Solution : appeler PHP avec "-d extension=..." pour chacune des extensions nécessaires (bizarement l'éditeur de php.ini fourni par Yulpa n'a pas l'air de faire ce qu'il faut). Au final, mon script "self-update.php" est le suivant : <?php if (!defined('PHP_BINARY')) define('PHP_BINARY', '/usr/bin/php'); $cmd = PHP_BINARY . " " . "-d extension=json.so -d extension=mysqli.so -d extension=dom.so -d extension=mbstring.so " . __DIR__ . DIRECTORY_SEPARATOR . 'update.php --feeds'; echo($cmd . "\n"); system($cmd); ?> La tâche planifiée exécute ce script toutes les heures. On peut aussi lancer la mise à jour manuellement via l'accès SSH : php self-update.php

simon$ dig +short txt 717._domainkey.mail.jakubowicz.me il n'y a en effet aucun enregistrement DKIM présent sur le sous domaine 717._domainkey.mail.jakubowicz.me, c'est ici que devrait se trouver la clé publique DKIM. Pour ce qui est de l'ip dynamique, les providers mails utilisent des DNSBL qui identifient les ips publiques d'ISP, et identifient les mails comme potentiellement douteux. (https://www.dnsbl.info/dnsbl-details.php?dnsbl=dul.dnsbl.sorbs.net par exemple) Beaucoup d'ordinateurs infectés (botnets) envoient des mails de façon incontrôlée via des ips dynamiques, le risque est donc fort, donc les emails présentant ce type de patterns sont beaucoup plus susceptibles d'être livrés en spambox

Bonjour, Une petite remarque toute bête sur la gestion des tâches planifiées : pour chaque tâche, il y a un bouton « voir l'historique de la tâche planifiée » qui affiche la sortie de chaque exécution. Cet historique est dans l'ordre chronologique, ce qui paraît sans doute naturel quand on a que quelques entrées dans la liste, mais c'est assez déroutant une fois que la tâche s'est exécutée beaucoup de fois : la dernière exécution (a priori celle qui nous intéresse le plus) se trouve à la fin de la liste, donc en bas de la 7 ème page vu que le système en archive 100 avec un affichage de 15 entrées par pages. Ça serait en fait beaucoup plus naturel en ordre chronologique inverse, avec la dernière exécution en haut de page 1. Pour la petite histoire, j'ai perdu pas mal de temps parce que je n'avais pas vérifié la date de la première entrée et que je croyais que c'était la dernière exécution. Je ne comprenais pas pourquoi mes modifs n'étaient pas prises en compte. On peut modifier l'ordre en cliquant sur le titre de la colonne, mais ça serait plus pratique à mon avis si l'ordre chronologique inverse était appliqué par défaut.

Bonjour, à titre d'infos, avoir un serveur de mails sur une IP dynamique et sur une IP FAI grand public est une très mauvaise idée pour la délivérabilité des mails. Le dynamique encore passera avec ce que vous mettez en place, mais pour l'envoi mieux vaut faire appel à un relay SMTP (on le fait si vous voulez).

Les deux ne sont pas compatibles, ce n'est pas une limitation Yulpa ici. Une entrée CNAME veut dire "redirige tout le trafic vers la cible du CNAME, quel que soit le type. Donc tout le trafic MX, A, TXT, etc... Est rédigé vers la cible du CNAME. Avoir une entrée MX et CNAME sur la même zone dns du même host est techniquement faisable mais un non-sens car le trafic est rédigé et l'entrée MX de la zone ne serait pas utilisée.

Hum, quelque chose m'échappe L'enregistrement MX (qui doit être le seul du domaine) doit ressembler à cela : Pas de raison que cela bloque, demo.dyndns.org doit être un enregistrement de type A, la RFC est donc respectée. De quel domaine s'agit-il ?

Bonsoir, Lors de la phase de création d'un compte, aucune indication n'est donnée quant à la politique de sécurité des mots de passe. Il serait toujours bénéfique pour l'utilisateur de lui indiquer clairement ce qu'on attend de lui. Il y a un nudge pour lui indiquer la qualité, c'est un premier pas ; mais il faudrait le coupler à un message claire sur le nombre de caractères si la taille est limitée, sur les caractères autorisés, etc. L'idée est de permettre à l'utilisateur d'imaginer son mot de passe en connaissance de cause, au lieu d'essayer... et de se faire refuser son mot de passe. L'utilisateur voit le mot de passe comme une contrainte, accepte de faire un effort d'imagination une fois, pas deux. La seconde fois, il adaptera simplement son premier essai en fonction du retour affiché, et utilisera quelque chose de beaucoup plus prédictif. C'est loin d'être par hasard que je remonte ça, puisque curieusement, le formulaire de connexion ne gère pas les mots de passe de plus de 50 caractères : "Le mot de passe doit comporter au minimum 6 caractères" (et autant dire qu'ils y sont). Du coup, l'utilisateur, tout heureux de pouvoir créer son mot de passe de 256 caractères (si si, il y en a... moi, déjà), reste tout bêtement à la porte au moment de se connecter. Autre souci : il est possible de mettre son identifiant en mot de passe. Identifiant : PN666-YULPA, mot de passe : PN666-YULPA. Il faut impérativement empêcher l'utilisateur de massacrer la sécurité de son compte avec ce genre de pratiques, et interdire également l'utilisation de son adresse mail comme mot de passe puisque j'imagine que c'est également possible. Un autre point qui pourrait être intéressant : coupler le process d'inscription avec l'API de HaveIBeenPwned.com qui permet de confronter le mot de passe proposé à une gigantesque liste de mots de passe présents dans les plus gros "leaks". Si le mot de passe figure dans une des listes : merci d'en choisir un autre, sinon on laisse passer. A noter que la v2 permet de tester un mot de passe sans avoir à le transmettre intégralement (uniquement les premiers caractères du hash en SHA-1). Merci !

Ça sonne bien ça ... Et ça marche ! C'est fou, dès que je bricole un peu sur mon site j'apprends des trucs.

Non chaque domaine et sous-domaines étant indépendant, si tu modifie la version de PHP il faut alors le faire sur chaque domaine utilisant ce WP.

Je pense avoir trouvé la réponse sur le site du registrar : Si j'ai bien compris, il est expiré mais il faut encore attendre deux mois pour avoir une chance de l'acheter...

Général - Diverses corrections de bugs. Utilisateurs - Lors de l’envoi du SMS pour la double authentification, seul les 4 derniers chiffres du numéro de téléphone sont désormais affichés dans la notification sur iWal. Http : PHP & SSL - Lors de l’ajout d’un domaine sur la plate forme web, le certificat SSL Let’s Encrypt est automatiquement créé. - Les certificats SSL sont désormais renouvelés à J-15 au lieu de J-10 afin de diminuer les alertes par les CMS et sites de supervision. - Les certificats Let’s Encrypt ne sont désormais plus affichés comme étant auto-signés dans iWal. - Il est désormais possible de modifier certaines valeurs opcache dans le php.ini Dns - Possibilité de créer des enregistrements DNS de type CAA pour définir les autorités de certification autorisé pour un domaine. Afficher l’article complet

Si jamais vous avez raté nos publications récentes sur les réseaux sociaux (ou si vous ne nous suivez pas 😢 ) sachez que depuis début mai, YULPA a pris un bureau au Remix Coworking afin de pouvoir évoluer dans un meilleur environnement de travail et préparer -nous l'espérons pour la fin de l'année- l'arrivée d'un premier employé.... Bon concernant le dernier point c'est pas encore fait, mais on y croit ! Bref, nous pouvons désormais vous recevoir dans les salles de réunion prévu à cet effet, ou autour d'un café si vous passez près de la gare Saint-Lazare (Paris 8). En prime, une petite photo

OK my bad j'ai lu l'info à moitié, tout fonctionne

Ce sera un domaine, un mail, une bdd, un de chaque en fait

à vos crons, prêt, go

à vos crons, prêt, go

Bonjour, comme système de listes de diffusion/discussion performant, je propose Sympa ; ça éviterait de réinventer la roue. Initialement développé en France par la communauté universitaire et donc très utilisé dans ce milieu, il propose de nombreuses fonctionnalités de gestion des autorisations, modération, archives, inscriptions/désinscriptions, traitement des situations d'erreur, réglage de la fréquence de réception des mails directement par chaque personne inscrite. De plus, ces interfaces de gestion seraient disjointes du manager, ce qui serait bien pratique.

Bonjour, c'est en cours de travail. Malheureusement, cette modification impose pour nous de travailler sur la création de nouveaux pool HTTP en apache2.4 Le monde de l'hébergement mutualisé est difficile en cas de changement majeur comme cette version de apache (htacces principalement) Dans le CMS à jour, on retrouve la prise en charge des deux règles de nommage pour certaines instruction qui permet d'assurer une compatibilité 2.2 et 2.4 + Mais de ce que j'ai vu, la grand majorité des .htacces seront non fonctionnels pour niveau gestion d'accès à une ressource. La question se pose donc . Basculer sur 2.4, et imposer aux clients de modifier leur .htaccess (sachant qu'il n'y à pas de risque d'exposer des données protégées par htaccess) une erreur 500 certainement sera affichée. Où mettre en place ce que nous voulons faire depuis 3 ans, diviser notre infrastructure HTTP en plusieurs pools . Des pools pourront rester en 2.2 et des nouveaux en 2.4 Donc, oui nous souhaitons passer en 2.4+ , prochainement oui, mais c'est quand même l'affaire de quelques mois.