Yves a écrit 401 commentaires

Merci pour la dépêche.

J’ai utilisé SOGo il y a longtemps, après avoir un peu galéré pour le compiler sur ARM (SheevaPlug). À l’époque, c’était révolutionnaire ! Beau, fonctionnel, complet, avec synchronisation… tout ça en open-source. Et relativement léger avec ça.

Puis j’ai commencé à rencontrer des problèmes inexpliqués de synchronisation (comme quelqu’un d’autre plus haut). De plus, j’étais très gêné par l’impossibilité d’utiliser plusieurs identités. Alors j’ai changé, d’abord vers DAViCal, puis vers ownCloud (nextCloud désormais).
Je suis sûr que la synchronisation a maintenant été améliorée. Mais quelqu’un signale dans un commentaire que le produit est toujours limité à une seule identité mail, 7 ans plus tard ! Dommage…

Pour info, SOGo n’est pas seul dans sa catégorie. OBM n’est pas mal non plus, quoique moins joli.
Et nextCloud couplé à Rainloop est très bien aussi.

J’imagine que ça dépend chez qui tu es. Pour moi (SFR, puis Bouygues Telecom), ça ne m’a jamais pénalisé.

En ce qui concerne le port 25, chez ces FAI, il est fermé par défaut mais peut être ouvert.

Même expérience pour moi au début : nombre de mes mails étaient rejetés ou même simplement perdus dans la nature…

Puis j’ai basculé sur un fonctionnement avec « smarthost » : tous mes mails passent par le serveur SMTP de mon hébergeur. Voici près de 10 ans que je fonctionne ainsi et je ne rencontre plus aucun problème. Et c’est compatible avec l’usage de SPF, DKIM etc.

Je ne suis pas d’accord avec l’affirmation que tu dépends de ton hébergeur. Le principe de smarthost est très répandu, et si celui de ton hébergeur (gratuit en principe) ne convient pas, tu peux t’inscrire sur un autre smarthost (généralement payant).
Ceci dit, après avoir été chez SFR, je suis maintenant chez Bouygues (ADSL dans les deux cas), et chez l’un comme chez l’autre, je n’ai aucune raison de me plaindre.

Au final, c’est tellement standard que tu ne dépends pas plus de ton hébergeur, qu’une prise murale te ferait dépendre d’un fournisseur d’électricité ;-)

De plus, c’est à peine plus centralisé que du pur auto-hébergement. Et tu gardes le bénéfice de la réception en direct des mails t’étant adressés (avec parfois l’impression que ton mail arrive avant que ton correspondant tél. te dise « ça y est, c’est parti » !)

Je suis en ADSL (2Mo/s en téléchargement, 60ko/s en téléversement).

Il est vrai que Nextcloud en accès distant, c’est limite (ne surtout pas accéder à des galeries de photos ou des films ; et Libre Office Online passe tout juste)

C’est par contre nettement suffisant pour le chat XMPP, la messagerie (SMTP/IMAP), le SSH (y compris tmux, alpine, elinks, irssi, poezio…) et la synchro de SMS, notes, contacts, calendriers et (petits) fichiers via les applis Android DAVDroid et Nextcloud.

Mon tout premier serveur auto-hébergé a été un PC format salon (format lecteur DVD), sur base d’une carte mini-itx EPIA M10000N.
Si le CPU et la carte mère m’ont satisfaits, le chipset graphique a été pour moi une grande déception.

Ça a été l’époque où j’ai dû fonctionner en permanence avec un kernel compilé à la mimine, un XFree86 (c’était avant Xorg) compilé de même, etc. avec des problèmes de compatibilité de versions car il fallait attendre l’aumône de VIA pour une nouvelle version déjà périmée du blob graphique qui irait bien…

De cette époque, j’ai retenu une chose : ne plus jamais acheter un matériel informatique ne disposant pas d’un pilote libre.

En tout cas, félicitations au projet OpenChrome, dont j’ai suivi le cheminement avec intérêt à ses débuts !

Étrange… Il est vrai que je n’ai pas essayé OnlyOffice (notamment à cause de son format de fichier de prédilection), mais je trouve LibreOffice Online plutôt abouti. Enfin, pour moi, c’est Collabora Online, mais c’est la même chose, j’imagine…

Je ne peux pas te dire spécifiquement pour le Raspberry Pi. Par contre, jusqu’à l’an dernier, j’utilisais comme serveur un eSata SheevaPlug, plus vieux et moins puissant que les Raspberry Pi. L’OS (Debian stable) était sur une carte SD 2GB.

Je l’ai changé parce que ça devenait intenable, mais il faut dire que je lui demandais beaucoup : SMTP, IMAP, XMPP, CardDAV, CalDAV, WebDAV, HTTP, DLNA, NFS, SSH, DNS, tunnels divers, PostgreSQL, et j’en passe !

Je te garantis que pour un usage raisonnable, un Raspberry Pi peut aller loin. Quant à la carte SD, tout ce que je peux dire, c’est que la mienne a tenu sans soucis jusqu’à ce jour (7 ans environ). Par contre, le contenu variant souvent (/var, /tmp, ainsi que toutes les données non-système) était sur un disque externe et non sur la carte SD.

Il manque le choix « 1 machine et quelques… » que j’aurais choisi s’il y était :-p

Je n’ai qu’un seul serveur matériel : Udoo X86. Par contre, j’utilise mon PC de bureau en backup primaire incrémental, et le cloud en backup secondaire (tout chiffré bien sûr).

J’ai un vague souvenir de l’ancêtre, début des années 2000, et je m’étais dit : ça n’est pas pour moi.

Aujourd’hui, je suis bien content que cette dépêche me fasse redécouvrir ce logiciel, qui pourrait bien être le complément tant attendu à ma plateforme d’échange XMPP auto-hébergée encore balbutiante (en attendant la version qui ira bien de Salut-à-Toi), et à laquelle il manque l’audio-vidéo.

Je sais bien que l’A/V avec XMPP, c’est possible, mais il faut pour cela un serveur TURN, et là, mon pauvre ADSL ne tiendra pas la route…

Il va falloir que je creuse du côté du pair-à-pair de Ring, pour voir si c’est compatible avec l’ADSL…

Sans rien installer, json_pp est en général déjà disponible : il vient avec perl 5. Entre autres choses, il permet de « jolifier » un flux JSON.

Quand tu développe une appli web où le « front » est en AngularJS, et le « back » en Java + Spring (MVC, JPA…).

Oui, mais tellement limitée, qu’il ne reste plus grand chose (ce qui n’est pas le cas de la version communautaire pour Python, Pycharm). Cf. tableau de comparaison :
https://www.jetbrains.com/idea/features/editions_comparison_matrix.html

Du Java sans JPA, sans Spring, sans AngularJS, etc. ça limite quand même pas mal l’usage…

Je suis très étonné du succès d’IntelliJ. Je ne dénigre pas l’outil, qui est très bon. Mais tous ces gens qui en sont si satisfaits ont-ils tous la licence nécessaire ? J’ai comme un doute…

J’aimerais savoir : quel est votre IDE préféré open source pour Java ?

J’ai jeté un coup d’œil à la démo : c’est impressionnant ! Ça me donne envie de proposer ça à mes utilisateurs auto-hébergés :-)
Y.

Le format Fail2ban n’est pas vraiment adapté à la philosophie de mon programme.
Cependant, ton idée a du mérite : elle enlèverait certainement un frein à l’utilisation de Pyruse…

Il est probablement possible de faire un convertisseur, qui lit la configuration de fail2ban et la transforme en configuration pour Pyruse.
Ce qui est dommage, c’est qu’un tel convertisseur ne serait sans doute pas capable de détecter les redondances et ainsi optimiser le fichier de configuration ; autrement dit : quel gain pour l’utilisateur ?

Je prévois par ailleurs quelques difficultés, notamment le fait qu’avec un peu de volonté, n’importe quoi peut être fait dans la configuration de fail2ban (cf. l’article que j’ai mis en lien dans le corps de la dépêche) : il faut donc récupérer chaque extrait de code (shell) et l’appeler par un module « wrapper » fait pour appeler du shell.

Bref, on va se retrouver avec un fichier de configuration non optimisé, qui n’utilise que des filtres et actions ad-hoc (aucun module standard), pour finalement exécuter du shell, et tout ça dans un mode opératoire nettement moins testé que la même configuration dans Fail2ban. Je ne suis pas optimiste…

L’erreur est réparée :-)
https://yalis.fr/git/yves/pyruse/src/branch/master/doc/install.md

Ça va venir :-) Il faut d’abord que je finalise certains points de ma configuration.

En fait, le(s) serveur(s) est entièrement configuré avec Ansible. Du coup, régulièrement je repasse le « playbook » et au passage ça fait les mises à jour.

En pratique, Archlinux sur un serveur, ça se passe plutôt bien. Avant cela, j’utilisais Debian.
Mon expérience (sur serveur) est celle-ci :

• Archlinux :
    − Il y a presque toujours un truc à gérer lors d’une mise à jour => hors de question de faire ça en automatique.
    + En contrepartie, les solutions aux problèmes qui se posent sont toujours simples et je sais que j’y arriverai toujours.
    + De plus, les logiciels sont toujours à jour et ça facilite beaucoup l’exploration de nouveaux usages.
    + Enfin, il est trivial d’empaqueter un nouveau logiciel, comme je l’ai fait d’ailleurs avec Pyruse ; donc pas d’étapes ./configure&&make install dans mon playbook Ansible.

• Debian :
    + Les mises-à-jour se passent généralement sans histoire.
    − Par contre, quand quand ça dérape, il faut réussir à s’imprégner des particularismes Debian, ce qui n’est pas toujours facile…
    + Les mises à jour de sécurité sont faites de manière sérieuse, ce qui compense l’ancienneté des paquets.
    − Mais plus le temps passe, plus il devient compliqué, voire impossible dans certains cas, de tester certains logiciels.

Tout est dans l’équilibre personnel recherché. Je suis parfaitement à l’aise avec la ligne de commande, et Archlinux convient mieux à mes objectifs. Mais il ne faut jamais être dogmatique : d’autres distributions peuvent mieux convenir à d’autres situations.

Mea culpa. Effectivement, j’ai oublié !
C’est empaqueté pour Archlinux, mais il faudrait quand même que je rédige une petite documentation. En attendant, avec quelques connaissances pour la ligne de commande, ceci peut aider :
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pyruse

Non, en réalité, je n’utilise pas 24h sur mon serveur, mais davantage (de l’ordre de la semaine). Je me suis déjà fait bannir, il y a longtemps… Tout comme Glandos, j’avais un accès shell-in-a-box pour rétablir l’accès. Désormais, je ne m’embête plus avec ça : j’utilise Termux sur mon Fairphone => IP différente ;-) Je peux aussi rebondir par un accès SSH tiers…

Au passage, oubliez l’idée de se protéger en changeant le port SSH : les scanners de ports trouvent le nouveau port sans difficulté, et je peux confirmer que ça n’empêche en rien les « attaques ». Bien sûr, sur un serveur bien configuré, ces attaques ont peu de chances de mener à quoi que ce soit…

Je ne peux pas généraliser à tout fichier JSON, mais dans le cas particulier de Pyruse, il faut savoir que les entrées de dictionnaire non utilisées sont ignorées, ce qui permet ceci par exemple :

"Détecter les accès SSH en échec": [
  { "INFO": "COMMENCER PAR VÉRIFIER QUE ÇA VIENT DE SSH",
    "filter": "filter_equals",
    "args": { "field": "_SYSTEMD_UNIT", "value": "sshd.service" }
  },
  { "INFO": "PUIS QU’ON A BIEN UN MESSAGE D’ÉCHEC DE CONNEXION",
    "filter": "filter_pcreAny",
    "args": { "field": "MESSAGE", "re": [
      "^Failed password for (?P<utilisateur>.*) from (?P<adresseIP>[^ ]*) port",
      "^Invalid user (?P<utilisateur>.*) from (?P<adresseIP>[^ ]*) port",
      "^User (?P<utilisateur>.*) from (?P<adresseIP>[^ ]*) not allowed because not listed in AllowUsers$"
    ] }
  },
  { "INFO": "SI C’EST BIEN LE CAS, ON AUGMENTE LE COMPTEUR",
    "action": "action_counterRaise",
    "args": { "counter": "sshd", "for": "adresseIP", "keepSeconds": 300, "save": "nbÉchecs" }
  },
  { "INFO": "ET S’IL EST SUPÉRIEUR OU ÉGAL À 4",
    "filter": "filter_greaterOrEquals",
    "args": { "field": "nbÉchecs", "value": 4 },
    "else": "… Ça ira pour cette fois, circulez !"
  },
  { "INFO": "ALORS ON BANNIT L’ADRESSE IP POUR 24H",
    "action": "action_nftBan",
    "args": {
      "IP": "adresseIP", "banSeconds": 86400,
      "nftSetIPv4": "Inet4 sshd_ban", "nftSetIPv6": "Inet6 sshd_ban"
    }
  }
],

C’est vrai que je n’avais pas pensé à ça !

D’ailleurs, Le journal systemd a cette même capacité de centralisation. Je surveille moi-même 2 hôtes avec Pyruse. Le champ _HOSTNAME me fournit l’hôte concerné.

Ah ah :-) C’est amusant : En lisant le titre de ton commentaire, je m’attendais exactement à l’inverse de ce que tu as finalement écrit.

En fait, si tu regardes, tout le code ainsi que la documentation sont en anglais ; rien en français. Tout le français que tu vois dans la dépêche est situé dans des clefs de dictionnaires Python. Ce ne sont que de quelconques chaînes de caractères.
D’ailleurs, tu noteras que le rapport quotidien est en anglais ; c’est une autre raison pour laquelle je souhaite mettre en place des « patrons » de génération à la place d’un rendu fixe.

Il y aurait donc bien un petit effort d’internationalisation à faire, pour rendre peut-être le logiciel plus accessible aux personnes non anglophones ;-)

Je comprends. C’est en effet intéressant quand tu gères une ferme de serveurs.

Avec Pyruse, il suffirait de créer un gestionnaire de compteurs alternatif adossé à une base de données (copier-coller de l’existant, avec juste un backend différent), puis d’implémenter les actions triviales +/−/reset.
La base de données pourrait être un PostgreSQL/MySQL… pour une grosse installation, ou peut-être un fichier SQLite sur partage réseau (quid des accès concurrents ?)…

Une autre solution, peut-être plus proche de ton idée, serait d’avoir un petit dæmon qui écoute en IP-Multicast : lorsqu’il reçoit une notification d’attaque, il la logue dans systemd. La conf. peut alors donner à cette « attaque » autant de poids qu’une véritable attaque locale. Et bien sûr, il y aurait une action à développer qui diffuse en IP-Multicast les attaques locales.

Bref… C’est possible :-)

Pas d’accord du tout.

J’ai également ce type de clef depuis bien longtemps. Mais là, on peut saluer le pragmatisme et l’astuce de l’auteur, pour avoir trouvé un processus de création du média adapté aux contraintes des logiciels installés. La démarche est efficace et semble bien ciblée, avec :

• un vrai besoin (je connais un formateur qui rêverais d’utiliser ça !) ;
• un résultat bien pensé, notamment sur l’ergonomie, qui a l’air bien équilibrée, entre modernisme et économie des ressources.

Bravo !

Merci :-) J’ai hâte de lire ça !