Foxy a écrit 660 commentaires

Merci pour ce (long) retour d'expérience sur l'hébergement de tes mails.

Je suis actuellement moi-aussi en cours de réflexion avec 2 options :

• tout héberger par moi-même sur un serveur (OpenBSD pour ma part car je maitrise ce système, tout comme Linux ; la diversité ne fait pas de mal). En passant, un très bon guide technique pour auto-héberger ses mails avec OpenBSD (Opensmtpd, Dovecot, rspamd) https://poolp.org/fr/posts/2019-12-23/mettre-en-place-un-serveur-de-mail-avec-opensmtpd-dovecot-et-rspamd/

• utiliser un service tiers pour SMTP, IMAP et CardAV/CaldAV comme Migadu ou le nouveau service français galae https://linuxfr.org/users/lebouquetin/journaux/publicite-galae-le-service-email-ethique-et-libre-et-francais-est-desormais-ouvert-o

Dans le cas d'un serveur auto-hébergé, un des gros problèmes recontrés est la réputation de l'IP du serveur. Si par malheur, l'IP de ton serveur est dans des plages "blacklistées" par les gros (Gmail, Outlook/Hotmail), au mieux, tes mails sont classés en Spam, au pire, pas de communication possible :(

Après des recherches, j'avais lu que les IP des serveurs/VPS de Hetzner, Vultr et OVH étaient souvent dans les blacklists. Et qu'en conséquence, il est déconseillé d'essayer de monter un serveur mail chez ses hébergeurs.

Pour ceux qui hébergent leurs mails (hors serveur @home avec IP fixe), est-ce que vous des retours sur le sujet ? Hébergeurs conseilllés pour un serveur mail ?

J'ai découvert le projet hier suite à la lecture d'un précédent billet (https://linuxfr.org/nodes/131547/comments/1926861) et ça m'a immédiatement intéressé pour héberger les mails d'un domaine perso. Même si j'ai l'expérience pour le faire, je ne veux plus auto-héberger mes mails, trop de services à maintenir (Postfix/Opensmptd, Dovecot, rspamd, greylist, RBL…) et trop de galères avec GMail/MS :( Je cherche donc un bon service SMTP/POP/IMAP comme le propose Galae.

J'en profite car j'ai quelques questions suite à la lecture des docs :

• est-ce que vous envisagez de déployer SMTP-AUTH et IMAPS pour renforcer la sécurité des protocoles d'envoi / relevé des mails ?

• développement/mise à dispo d'une API pour automatiser certaines tâches, création des comptes particulièrement. Je rêve ou c'est de l'ordre du possible ?

• l'offre "Start" à 20€ HT/an me parait bien pour mon usage perso. Néanmoins, je me demande si le quota de 35 messages/jour en envoi n'est pas un peu juste pour mon usage (mails perso, réponses mailing-listes, autres…). Est-ce qu'il est prévu de pouvoir facilement migrer d'une offre vers une autre (ici Start => Evolution) en cas de besoin ?

Triste nouvelle :-'(

J'ai découvert Vim il y a maintenant 30 ans… lors de ma découverte d'Unix et mes 1ères expérimentations de Linux. Comme tout à chacun, j'ai été au départ déconcerté par cet éditeur (les modes Normal/Insertion, comment sortir de Vim avec le fameux :wq!…) mais une fois pris en main, on ne le lâche plus.

Une fois enrichi de (nombreux) plugins et pas mal d'heures de configuration, il fût mon éditeur de texte/code principal et utilisé sur toutes mes machines/serveurs. Je ne l'ai jamais quitté jusqu'à peu (passage à Neovim depuis 2 ans).

Joyeux anniversaire LinuxFR, 25 ans ça se fête :)

Je ne participe presque plus, je ne consulte plus le site que de manière épisodique mais cela ma rappelle mes "jeunes" années sur Linux. Si j'en crois les archives, ma 1ère news date de juin 1999 mais il me semble que j'étais présent quasiment dès les débuts du site.

Je viens de downloader le fichier ePub pour cette version du guide. Aucun problème pour moi : j'ai bien une couverture, une table des matières et des liens cliquables dans le corps du texte :)

Vérifié avec les softs Foliate (GUI) et epr (mode terminal).

Jolie investigation de ce scanner « fantôme ».

Ce que je retiens, c'est que d'après ton screenshot, c'était un scan de la couverture du livre « Gödel, Escher, Bach » de Douglas Hofstadter, très saine lecture :)

Merci pour ce CR très complet et pour ton travail pour maintenir/développer ce fabuleux outil qu'est Gimp.

Vu l'ampleur des modifications proposées, on peut imaginer qu'il va y avoir de nombreuses étapes d'intégration et de tests : merge sur des branches de travail, review croisée du code, recompilation du noyau dans plein de configurations/architectures différentes et tests.

Le patch concernant quasi exclusivement les fichiers d'include, le risque principal de régression est de s'assurer que le noyau compile correctement avec une grande variété de configuration des options choisies.

Joli projet et très intéressant pour le domaine du RE.

Mais si je m'en réfère à ton schéma d'architecture, cela me parait très ambitieux : vouloir supporter plusieurs hyperviseurs, des stubs KD et GDB (donc OS Windows et Linux comme guest) et le tout en passant uniquement par VMI, de ce que j'en connais ce sera difficilement atteignable.
Viser un seul hyperviseur cible parait être plus réaliste. Et tant qu'à faire en en choisissant un dont les sources sont modifiables afin de pouvoir y ajouter des fonctions de debug avancées si nécessaires; donc à priori KVM/qemu, Xen ou VirtualBox.

Dans le même ordre d'idée, le projet Sandbagility est un framework d'introspection de VM Windows utilisé aussi pour faire du RE (dev open-source par des malware analystes de Orange Cyberdefense). C'est développé en Python et repose sur des ajouts à VirtualBox pour avoir un protocole de debug avancé (Fast Debugging Protocol). Voir par exemple la présentation qui en a été fait à la conf. SSTIC en 2018 https://www.sstic.org/2018/presentation/sandbagility/

Ces travaux découlent du projet Mancoosi [http://www.mancoosi.org/] auquel participe l'équipe PPS de l'Université Parsi VII dont font partie Stefano Zacchiroli et Roberto Di Cosmo [http://www.pps.jussieu.fr/].

Sur le site de Mancoosi, on peut trouver pas mal d'articles de recherches sur la complexité de la gestion des dépendances logicielles.

Je recommande particulièrement la lecture du papier "Strong Dependencies between Software Components" [http://www.mancoosi.org/papers/esem-2009.pdf] qui présente les dépendances des packages de la distribution Debian (avec plein de théorie des graphes de ands ;) ).

A cette occasion, les devs d'OpenBSD ont réalisé et mis à jour le port OpenBSD d'Asterisk "Music On Hold" ("musique d'attente" lors d'un appel VoIP sur un serveur PABX Asterisk) avec la chanson polémique contre Stallman : http://openports.se/telephony/asterisk-openbsd-moh

M'en fout (comme de la Debian d'ailleurs ;-) ), ils peuvent toujours "moinsser", je suis un des plus vieux pseudos ici et un des20 premiers en nombre de points (du temps ou ils étaient affichés). Donc je risque pas de perdre mon "droit de vote".

Au lieu de me "moinsser" comme des fous, vous pourriez faire l'effort de me répondre et d'argumenter !

Mouais m'en fout de toute façon, j'utilise pas la Debian.

Mais si les membres du projet Debian passaient plus de temps à coder, tester et releaser qu'à "jouer à la petite démocratie libre", peut-être que la Debian perdrait pas des utilisateurs tous les jours et que la Sarge serait déjà sortie.

De ce que je lis et vois, le projet Debian est très bon pour s'auto-gérer, pour que tous les avis soient pris en compte et que l'avis majoritaire l'emporte. Mais ils sont incapables d'arriver à suivre une roadmap de sortie d'une version.

Si c'était dans le milieu professionnel, y'a longtemps que le projet aurait été abandonné ou mis sur une étagère en l'état.

Finalement, ce n'est peut-être pas une aussi mauvaise nouvelle que ça.

L'équipe de développement du kernel va être un peu embétée pendant un moment car certains développeurs vont devoir se passer du client BitKeeper non commercial.

Mais on peut espérer que le développement du Linux kernel passe sur un système de gestion de version libre et open-source : Subversion et Arch sont tout à fait à même d'être utilisé pour remplacer BK (même s'ils manquant encore des fonctionnalités). D'ailleurs certains devs comme Andrea Archangeli utilise déjà des passerelles BK - CVS - Subversion pour leur dev et s'en sortent très bien.

Cela permettra aussi que d'autres projets open-source suivent cette voie car à l'heure actuelle, difficile de faire bouger les gens pour ne plus utiliser l'antique CVS.

Pour avoir essayé Tor et lu les papiers techniques à son propos, c'est un des meilleurs outils réseaux pour dissimuler ses activités sur Internet.

Tous les noeuds du réseau Tor ne permettent pas de sortir vers tous les ports TCP/IP (entre autre peu de sortie sur le port SMTP/25 pour éviter que le réseau Tor soit utilisé pour spammer) et le réseau n'est pas conçu pour les applications très consommatrices en ressources réseau (par ex. les applis P2P comme Bittorrent).

Les liens sont chiffrés entre chaque noeud Tor : c'est le principe même de l'Onion Routing dont Tor n'est qu'une application.

Allez lire le site de Tor : http://tor.eff.org(...) et les papiers disponibles : c'est une mine d'info sur le sujet. Pourquoi croyez-vous que l'EFF mette autant en avant cet outil depuis quelques semaines ?

Trop fort, Yaya arrive pas à hacker le switch de sa boite (ou celui de sa fac) et il poste sur LinuxFr pour avoir de l'aide. Y'en a qui doute vraiment de rien...

Euh... les machines de tests vous connaissez ???

Perso, les développeurs kernel que je cotoie, ils testent pas leurs développements noyau sur la machine qu'il utilise pour développer. Ils bootent leur kernel à tester sur des machines de tests reservées à cela. Et on s'arrange pour avoir des solutions de réinstallation de ces machines : boot réseau, images de backup du système...

Mais bon, je ne sais pas quel distrib Linux Linus utilise.

Tu n'as qu'à contacter l'ALDIL (LUG lyonnais) http://www.aldil.org(...) sur leurs mailling-listes. Il y aura certainement quelqu'un pour te répondre à ce sujet.

Tiens ça me fait penser que ça fait bien longtemps que j'ai pas vu une discussion sur LinuxFr qui dérive au point qu'elle se conclue avec un magnifique point Godwin.

Ca doit être la maturité des lecteurs et rédacteurs sur le site qui veut ça ;-)

Par ailleurs pour ce qui est de remplacer les Catalyst (enfin plutôt les routeurs), c'est plutôt le travail de XORP.

Tout à fait et un des objectifs du projet OpenBSD est de très bien supporter XOrp sur OpenBSD.

En plus du développement des démons OpenBGPD et OpenOSFD, on peut aussi noter l'implémentation récente du Multipath Routing et du Protocol Independent Multipath (http://undeadly.org/cgi?action=article&sid=20050115003448(...))

exactement. d'autant plus que le copyright étant ce qu'il est, ils doivent "citer leurs sources", ce qui fait de la pub pour OpenBSD si un bon système propriétaire se base sur leurs logiciels (cf. Darwin, et d'autres).

Désolé mais ça fait bien longtemps que la clause de "publicité" de la licence BSD a été retirée de la licence BSD-like utilisée par le projet OpenBSD (et donc OpenOSPFD).

Donc quelqu'un qui utilise du code OpenBSD pour un projet "closed source" n'est pas obligé de le dire :-(

Oui, l'écriture d'un démon HTTP par l'équipe d'OpenBSD viendra certainement un jour pour remplacer Apache.

A l'heure actuelle, depuis les modifications de la licence Apache, le projet OpenBSD ne met plus les sources à jour mais corrigent seulement les problèmes de sécurité.

Allez pour mémoire relisez l'article d'ACM 85 de Ken Thompson sur la problématique de sécurité du code d'un compilateur compilé par lui-même.

Comme ça, ça fera encore plus de questions philosophiques ;-)

Modifiables, non, mais certains peuvent être éliminés (le statut UNCONFIRMED est desactivé par défaut, l'utilisation de VERIFIE D est facultatif, etc...)

Le Statut VERIFED, c'est mon préféré lorsque j'ai vérifié que les devs ont bien fait leur boulot et que leur correction est validée ;-)