dani a écrit 116 commentaires

Pour les fichiers, pour moi c'est Seafile. Je pense qu'il coche toutes les cases (sauf peut être le client sur f-droid, ça je suis pas sûr, j'utilise celui du playstore). Pour le reste, c'est fiable et performant. Couplé avec OnlyOffice pour l'édition en ligne, ça fait un truc confortable.

Pour les emails+agendas+contacts, pour l'instant c'est Zimbra (un peu lourd à installer, mais bien complet fonctionnellement). Je lui met un Proxmox Mail Gateway en frontal pour le filtrage. Malheureusement, son avenir à Zimbra est un peu incertain (plus de build de la version communautaire, il faut le faire soit même, nouvelle interface web non libre réservée à la version NE etc.). Je vais peut être regarder du côté de Carbonio un jour où j'aurai le temps. C'est un secteur où les solutions libres ont vraiment du mal à exister, l'offre est très limitée, et le peu de solution existantes se referment petit à petit (la version libre ne servant plus que de démo à une version propriétaire)

Deux outils excellents que j'utilise tous les jours (en plus de ceux déjà cités) : BackupPC et Lemonldap::NG. Sinon perso, je trouve perl très adapté pour des petits scripts vite fait (monitoring, traitement de données one-shot etc.)

Plus qu'une question de sécurité intrinsèque (Windows a fait d'énormes progrès depuis l'époque où c'était une passoire), c'est surtout une question d'uniformisation je pense. Les OS basés sur Linux sont bien plus variés (distributions différentes, plusieurs versions majeures maintenues en parallèle, mises à jour moins automatisées que Windows, et donc potentiellement encore plus de différences entre machines même si version majeure identique). Je pense que c'est ça qui fait que c'est moins rentable de s'y attaquer : ça demanderait de spécialiser une attaque presque pour chaque machine

Utilisateur de PfSense et OPNSense depuis un moment, le projet semble intéressant. Ce qui me manque, c'est les différences entre OPNSense et DynFi, du point de vue utilisateur (quelles fonctionnalités ont été ajoutées / supprimées). Et est-ce qu'il y a une roadmap définie ?

Ouais, ce problème est un peu relou. Surtout, il dépend énormément de la chaîne de certificats intermédiaires transmise par le serveur, et de la lib TLS côté client qui fait la vérification. Pour certains clients ACME (tous ?), la chaîne intermédiaire par défaut inclue la racine de Let's Encrypt (ISRG Root X1), mais sous sa forme "cross-signed" par l'autorité DST Root CA X3 (celle qui a expiré hier)
C'était fait comme ça pour que Let's Encrypt puisse être reconnu, le temps que sa propre autorité ISRG Root X1 (sous sa forme d'autorité, donc auto-signée) soit diffusée un peu partout.

Maintenant, il y a plusieurs cas de figure. Pour certains clients, quand ils vérifient la chaîne, ils identifient le R3 (intermédiaire de Let's Encrypt), qu'il est bien signé par l'ISRG Root X1, et que ce ISRG Root X1 est bien présent dans leur magasin de confiance, et donc s'arrêtent là, sans remonter plus haut, la connexion marche, tout le monde est content.

Mais d'autres clients n'ont pas ce comportement. Il trouvent bien le ISRG Root X1 dans la chaîne, mais comme il est signé par la DST Root CA X3, ils continuent la vérification, et remonte à l'autorité DST Root CA X3. Et comme le DST est expiré, boum, ça casse.

Il faut donc d'une part que les magasins de certificats soient bien à jour sur les clients (pour qu'ils possèdent le ISRG Root X1), et que le serveur modifie sa chaîne d'intermédiaires pour ne plus présenter la forme signée par DST de l'ISRG Root X1.

Mais en faisant ça, on perd bien sûr la validation sur les vieux appareils, qui n'ont pas l'ISRG dans leur magasin. Bref, aucune solution n'est idéale

Demande à ClamAV et spamassassin ce qu'ils en pensent

J'adopte ton nouveau verbe :-) (je me suis fait strasbourgifier 5 serveurs dédiés)

Alors, si on voulait faire de l'absurde :

• spam => ça peut offenser les vegans
• web => ça peut offenser les arachnophobes
• ruby => ça peut offenser ceux qui souffrent du trafic de pierres précieuses
• bloat => mais c'est de la grossophobie ça !
• navigateur => OMG, ça rappelle tellement les colons, il faut vite changer ce terme
• système de fichier => c'est pas très respectueux des anarchistes, qui sont anti-système
• ticket => Rhooo, mais c'est une référence à la guerre et aux tickets de rationnement, va falloir renommer ça et vite !

Des références connotées négativement, on peut en trouver avec tout et n'importe quoi, et on trouvera toujours quelqu'un pour prétendre être offensé. Libre à vous de penser que pour tous ces exemples idiots il faudrait vraiment trouver des alternatives ou pas …

Il se trouve que je ne suis pas impacté, donc ça ne me gène pas. Je comprend par contre ceux qui le sont. Et ça n'a rien à voir avec l'égoïsme ou s'intéresser qu'à soit. On parle d'une branche d'un logiciel. En quoi le terme master, dans ce contexte, serait une quelconque référence à l'esclavagisme ou à un autre délire du genre ? Je veux bien changer d'avis si on m'expose des arguments, mais jusqu'ici, j'ai rien vu de convaincant. C'est quoi le problème ? Le mot lui même ? Dans ce cas, il ne faut pas juste changer le nom des branches Git, il faut refaire les dictionnaires en bannissant ce terme (sinon des gens pourraient être offensés en ouvrant un dictionnaire).

Bah c'est un changement qui n'apporte rien. Alors, pour ceux qui n'ont rien à faire de leurs journées, non bien sûr, ça n'est pas un problème. Pour ceux qui sont occupés, avec de vrais problèmes à résoudre, c'est juste un truc en plus. Et les trucs en plus qui n'apportent rien, en général, ça fait râler.

Il démarre en root mais drop ses privilèges par la suite. À noter qu'avec systemd, c'est facile de donner la capability à un process non privilégié (j'ai pas testé avec nginx, mais avec d'autres services)

Sinon, moi c'est nginx que je recommande. Je ne sais pas si c'est le meilleur, mais il est très performant, sa configuration est assez souple, bref, pour la plupart des cas d'usage, il convient parfaitement

Tout est question d'équilibre entre avantages et inconvénients. De mon point de vu, pour la plupart des usages, les solutions "en ligne" apportent plus d'avantages, donc je les privilégie

Non, je ne parle pas spécifiquement du cloud. Je ne fais que des déploiements on-prem. Et je privilégie autant que possible les appli "en ligne" (vs les clients lourds), et libres bien sûr

Il y a pleins d'autres intérêts (simplifier et garantir les mises à jour, faire de l'édition collaborative, forcer le stockage des données sur un support correctement sauvegardé, limiter les appels au support etc.)

A terme, une fois la transition terminée, IPv6 sera aussi "simple" que IPv4

C'est bien là le cœur du problème : la transition ne sera jamais terminée.

Ça s’appelle la paresse

On a tous des ressources limitées. Ne pas les allouer à un déploiement d'IPv6 (qui en demande beaucoup, sans apporter d'intérêt immédiat) n'est pas déconnant, et n'a rien à voir avec de la paresse. C'est juste de l'arbitrage.

Pour clarifier mon point de vue : je travaille principalement pour des PME.

Pour des particuliers qui se contentent de se brancher derrière une box, oui, IPv6 n'apporte pas vraiment de contrainte. Tu branches, ça marche et voilà. Pour les grands groupes, ils ont des équipes dédiées, et de bonnes raisons de passer sur IPv6 (saturation des plages RFC1918, pb d'interco de site, coût des équipements se chargeant du NAT, conquêtes de marchés émergents potentiellement en IPv6 uniquement etc.)

Puis au milieu de ça, il y a les structures intermédiaires. Chez qui les équipes techniques sont déjà sous dimensionnées (quand elles existent), les coûts des équipements se chargeant du NAT sont négligeables, il n'y a pas de pb de saturation de plages privées, pas ou peu de pb d'interco de sites, et tous leurs clients peuvent les joindre en IPv4. Bref, dans ces cas là, l'IPv6 n'apporte pas de gain. Ni à court, ni à moyen terme. Pour quelle raison celui qui signe les chèques en ferait un pour ça ?

Un autre problème qui vient avec l'IPv6 pour ces structures : ça les lie fortement à leur opérateur. Et souvent, elles aiment pas ça (et je les comprend). Le jour où tu veux changer d'opérateur, tu dois refaire tout ton plan d'adressage interne. À moins de n'utiliser que les adresses fd00:/8 en interne, mais du coup, ça supprime une partie des avantages de l'IPv6.

Bref, de mon point de vue, c'est surtout pour ces structures intermédiaires (mais nombreuses) que l'IPv6 représente un coût démesuré par rapport aux gains (à peu de choses près nuls)

en quoi est-il plus complexe?

Pratiquement tout, puisque IPv6 ne fait que s'ajouter à l'existant, et qu'il est quand même bien différents de son grand frère. Plus de proxy ARP (ok, il faut voir pour faire du proxy NDP à la place), plus de failover/loadbalancing de lien WAN (à part les gros qui peuvent négocier des échanges BGP de leurs plages avec différents providers), énormément de choix à faire : je fais du statique, du SLAAC, du DHCPv6 ? Mon provider me fournit un /48, ou bien un /56, ou encore un /64. Avec délégation de préfixe ? Comment je redécoupe en réseaux étanches en interne. Et tous ces choix doivent être refait pour s'adapter à chaque situations, parce que les fournisseurs ne font pas tous pareil (l'IPv6 entre OVH et Scaleway par exemple, et pas du tout géré pareil).

Ah oui aussi, je dois dupliquer toutes les règles de pare feu. Et toutes les entrées DNS.

Enfin bref, c'est évident qu'IPv6 est extraordinairement complexe par rapport aux gains apportés maintenant (petit à petit, les gains seront plus importants, et donc le coût baissera, mais on n'y est pas encore …)

Pourquoi ne pas implémenter que l'IPv6 ? C'est géré par les OS, les navigateurs, le réseau, les DNS… Ah je reconnais que c'est plus chiant à taper.

La question est plutôt : pourquoi implémenter l'IPv6. Puisqu'il ne permet pas grand chose de plus que l'IPv4 dans l'énorme majorité des cas. Et est bien plus complexe (et donc coûteux) à mettre en place. Quand à faire de l'IPv6 only, je vois pas qui se permettrait de faire ça. Ça n'a aucun sens de se couper de la plus grosse partie d'Internet. Il faut et faudra pendant encore des décennies de l'IPv4 (que ça soit en dual stack ou via du 6to4)

Une solution technique qui a besoin de législation pour s'imposer est sans doute une mauvaise solution technique. Soit il y a un vrai besoin d'IPv6, et il devrait se déployer naturellement. Soit il n'y en a pas besoin, donc les acteurs traînent les pieds. Mais dans ce cas, pourquoi la législation devrait forcer son déploiement, si il n'y en a pas besoin ? Non pas qu'il n'y a aucun intérêt à y passer, mais ça semble apporter plus de problèmes que de solutions. L'IPv4 est de toute façon là pour rester. Donc on devra se taper une double stack indéfiniment. Du coup, la solution à la pénurie d'IP qu'est le NAT, aussi imparfaite soit-elle, est elle aussi là pour rester. Déployer l'IPv6 ne fait qu'ajouter toute une montagne de problèmes et de coûts supplémentaires, sans véritable gain (dans la majorité des cas)

Bof, il pourrait y avoir toutes les lois du monde, ça changera rien au fait que dans 20 ans, on sera toujours à faire majoritairement de l'ipv4. La législation ne pourra pas faire grand chose contre le cuisant échec de l'ipv6

Si ce qui est affirmé plus haut est faux, et je le démonte dans mon commentaire.

À part un péremptoire "c'est faux", tu n'ajoutes pas grand chose de concret. Pour qu'une fonction puisse être utilisée, bien sûr il faut que les clients l'implémentent, ça paraît naturel. Le problème n'est pas là. Le problème est que rien ne garantie que les clients utilisés implémenteront tous cette fonction. Donc dans les faits, ce qui est sûr de fonctionner, c'est le plus petit dénominateur commun (c-a-d, presque rien). Le reste peut, peut être, avec un peu de chance marcher.

Même si les 2 implémentent une fonctions censées être similaire, ça ne fonctionnera souvent pas (à l'époque, il suffisait d'essayer de passer un appel A/V entre un Gajim et un Empathy pour rire. Je suppose que c'est toujours à peu près autant le bordel entre clients différents de nos jours)

Et à ça s'ajoute aussi le problème des serveurs (même si tu l'as balayé d'un revers de la main, en finissant par admettre que si, finalement, il faut que les serveurs eux aussi implémentent des trucs … optionnels). Là encore, un utilisateur n'a aucun moyen de contrôler ça. Tiens d'ailleurs, le transfert de fichier aussi nécessitent le support côté serveur …

Et un utilisateur normal, tu lui fais tester un truc qui marche pas une fois, OK il tolère. 2 fois, il se fout de ta gueule, 3 fois il va chez la concurrence, là où les choses marchent.

Bref, on peut simplifier : dans un réseau fédéré, ce qui est optionnel doit être considéré comme absent.

Ça c'est faux. Il y a très peu de fonctionnalités qui demandent que toute la chaîne implémente quelque chose (en fait je n'en vois aucune là tout de suite), excepté PEP qui est implémenté par absolument tout le monde (c'est nécessaire pour publier des infos comme des clefs publiques). L'audio vidéo peut fonctionner si uniquement les clients l'implémentent, le serveur ne fait que fournir une aide pour traverser les réseau difficiles, et même là il suffit qu'un des 2 serveurs implémente ce qu'il faut.

Tu dis toi même qu'il faut que les 2 clients implémentent les mêmes XEP, et au moins pour certaines, il faut aussi le support des serveurs. Me semble difficile de commencer ta phrase par un simple "ça c'est faux" du coup. On est bien d'accord qu'en dehors des fonctions les plus basiques, il faut que tous les participants utilisent un client qui supportent des XEP, qui sont optionnelles …

L'envoi de fichier marche à ma connaissance avec tous les clients et serveurs, ça fait combien d'années que tu n'as pas essayé ?

Je m'en suis servi de 2007 à 2017 en gros, principalement avec Ejabberd et divers clients sous Linux. Et mon expérience était plutôt : ça ne marche jamais, sauf exceptions (à condition que les 2 utilisent le même clients, dans la même version et soient sur le même LAN en gros …). Tous les clients existants étaient au mieux médiocres (Gajim, Empathy, Psy, Pidgin, Jappix en web). Peut être que ça s'est amélioré ces 3 dernières années, mais enfin, faut se rendre à l'évidence : XMPP ne fonctionnera jamais en vrai. La XSF aurait pu en faire un vrai succès, mais au lieu de faire un client et un serveur de référence (par exemple), ils ont préféré écrire 45 XEP différentes rien que pour l'envoi de fichiers. Et démerdez vous les développeurs pour trier dans ce tas de trucs ce que vous voulez implémenter.

Oui, monter un serveur XMPP privé, et où l'on contrôle tous les clients (typiquement pour un usage interne en entreprise) c'est simple, et en effet, on peut plus ou moins s'assurer que toutes les fonctions de base seront dispo. Mais ça, c'est oublier que XMPP est fédéré (sinon, il n'a plus aucun intérêt). Et avec la fédération, tu n'as aucun contrôle sur le serveur de tes interlocuteurs, ni de leur client. Et là, XMPP retombe au plus petit dénominateur commun (tu seras à peu près sûr que tu pourras échanger des messages textes, probablement participer à des salons. Pour tout le reste, ça sera aléatoire)

Dans la balance Matrix vs XMPP, il y a quelques éléments quand même en faveur de Matrix (qui m'ont fait quitter XMPP pour Matrix il y a 3 ans, sans regret) :
- Les salons sont distribués sur tous les serveurs qui y participent. Il n'est donc pas possible de faire fermer un salon en supprimant un serveur qui l'hébergerait
- Le protocole est versionné au lieu d'avoir un cœur simpliste et toute une collection d'extensions optionnelles. C'est ce qui fait que XMPP ne marche pas dans le monde réel : pour pouvoir utiliser des fonctions élémentaires, il faut que toute la chaîne (ton client, ton serveur, le serveur de ton interlocuteur, le client de ton interlocuteur) supporte les mêmes XEP et que tout soit bien configuré. Comme c'est rarement le cas, et qu'il n'y a aucune façon de le garantir … On fini par ne plus l'utiliser pour envoyer des fichiers par exemple (puisque trop de risque que ça ne passe pas). Je parle même pas d'appels audio/vidéo. Avec Matrix, ça juste marche.