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

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

Ce sujet ayant été visionné de nombreuses fois, il vaut peut-être la peine de dire où j'en suis. J'ai ouvert un ticket qui n'a pas abouti et que j'ai donc clôturé. La seule solution que j'ai trouvée, ne souhaitant pas quitter yulpa, est de changer de programme de cache. Et effectivement, plus d'erreurs depuis. Mais les utilisateurs de Comet cache, en tout cas de Comet cache pro doivent savoir que la même erreur peut leur advenir ici

Bonjour, Merci pour les informations. Je n’avais pas pensé à git, je vais comparer avec rsync et sftp. Cordialement, DamienT

Merci pour votre efficacité ! ^_^

Problème résolu sur le chat. Bug iWal : le certificat LE n'avait pas été retiré de l'ancien hébergement après suppression du domaine

Bonjour, bizarre, le certificat aurait dû être supprimé par iWal au moment de la suppression du domaine Pouvez vous me dire quel est le domaine en question ? PS : ou contactez nous sur le chat en bas à droite de iWal / du site.

Je n'avais pas vu la réponse... À cette heure-ci, je suis bluffée ;-) Alors oui, effectivement, le domaine a changé d'hébergement. J'ai tout supprimé ce qui correspondait à l'ancien et tout recréé sur le nouveau mais avait un peu peur de supprimer le certificat sur l'ancien hébergement pour le recréer sur le nouveau. Donc, puisque ça n'est pas gênant, je vais aller le supprimer puis le recréer sur le nouvel hébergement de ce pas ;-) Merci pour votre réponse (plus que) rapide !

Bonjour, vous parlez de passer le domaine d'un hébergement à un autre non plutôt ? Attention en faisant cela, vous allez aussi supprimer les comptes emails du domaines. Pour le SSL en effet il faudra le refaire mais cela n'est gênant de résilier le certificat existant et de le refaire sur un autre hébergement dans la foulée

En effet, très bonne nouvelle le retour de cette offre

Bonjour à tous, je viens d'écrire un petit tuto sur ce sujet : http://blogmotion.fr/systeme/htaccess-http-https-erreur-16358 Pensez aussi à votre référencement, à ajouter le site HTTPS dans Google Console (anciennement webmaster tools). Vos retours sont les bienvenus

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.