Leaderboard

Bonsoir, Sur les hébergements mutualisés, ce ne sera pas possible d'installer ces composants. Discourse est en Ruby et les hébergements Yulpa ne proposent pas de prise en charge Ruby de ce que je sais. Quant à Docker, impossible d'installer ça sur un hébergement mutualisé, c'est exclu, au minimum sur un VPS, il me semble que c'est quelque chose que Yulpa peut proposer, à voir avec eux peut-être dans un ticket support ? shawn.arildsen@wormedia.com

Bonjour, Après avori galéré pour configurer mes calendrier Yulpa sur l'application Calendrier de Mac OS voici les paramétrages qui fonctionne pour moi: Dans l'application Calendrier, je fais dans le menu Calendrier/Préférences puis l'onglet Comptes Je clique sur "+" pour rajouter un calendrier, choisi d'ajouter un compte CalDAV En mode Type de compte Avancé, je configure comme suit: Nom d'utilisateur : mon adresse mail mot de passe adresse de serveur: mail-zose.yulpa.io chemin du serveur: /principals/users/<mon_adresse_mail>/ Je coche "Utiliser SSL" mais ne spécifie pas de port Pour ma part, il a fallut que je redémarre ensuite l'application pour que le calendrier fonctionne Espérant que cela permettra à certain de gagner du temps

bonjour, j'ai depuis hier un souci de synchro des contacts et agenda sur mon ordiphone via DavDroid. Serait-ce lié à ce changement ? si oui, la période transitoire serait plus courte qu'annoncé ...

merci Yulpa, fait sans soucis!

Ça a l’air nettement mieux!

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

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.