Yves a écrit 383 commentaires

Oui. ConEmu est très bon. Il est livré par défaut je crois avec Portable Cygwin et remplit bien son rôle.
Ceci dit, mintty fourni de base avec Cygwin officiel est très bien aussi.

Parce qu’un conteneur façon Docker (ici, je ne parle pas de LXC/D, nspawn, etc.), c’est une application, pas un OS.

C’est un bon projet. Et tu as raison, cette présentation arrive à propos.
Pour que ce soit vraiment abouti, il faudrait je pense enlever le « presque », c’est à dire que le paquet final soit installable, comme le propose checkinstall.

Si certains formats demandent des informations spécifiques impossibles à inclure dans le format–pivot, je vois 3 solutions, utilisables ensemble ou séparément, au choix :

• les enregistrer au préalable dans un fichier de configuration (comme checkinstall)
• les passer en paramètre (comme avec les archétypes Maven)
• les demander interactivement (les deux outils font ça)

Salut à tous,

Un grand merci à LinuxFR et aux Éditions ENI pour le livre que m’a apporté cet article.
Pourquoi ce cadeau ? Parce que vous avez été nombreux à être intéressés par Pyruse (quelqu’un a même créé un ticket pour suggérer le support d’iptables, qui pourrait donc finalement faire son entrée ultérieurement).

Du coup, vous serez sans doute intéressés de savoir qu’il y a des évolutions :

• une procédure d’installation (dites-moi si vous rencontrez des problèmes avec) ;
• le choix du niveau de détail (concernant les dates+heures) associé à chaque message du rapport quotidien ;
• le filtre d’appartenance à des plages d’IP, ce qui permet de faire des « whitelist » et « blacklist » ;
• l’action de log dans le journal systemd, qui permet la détection de récidive, avec autant de niveaux que souhaité.

Et en ce moment, je travaille à l’ajout d’actions de gestion du DNAT (ou autre mécanisme de proxy). Vous avez sans doute déjà rencontré ce problème : vous avez des attaques (SSH, HTTP…) et elles proviennent toutes de « 127.0.0.1 » ou « 10.0.0.1 » (votre proxy)…

La solution que je vais mettre en place fonctionne en 2 temps :

1. Une action travaille sur les logs du pare-feu, ou de haproxy, pour associer 3 adresses+port : le client, le proxy, la destination.
2. Une autre action permet de substituer des valeurs de variables en fonction de la correspondance établie à la première étape.

Exemple :

1. Le client 12.34.56.78:23456 se connecte à votre serveur 87.65.43.21:443 (haproxy), qui utilise la socket locale 10.0.0.1:12345 pour relayer l’appel en mode TCP à OpenSSH sur 10.0.0.2:22.
2. Une chaîne d’exécution va :
   • extraire des logs haproxy les infos 12.34.56.78:23456, 10.0.0.1:12345, 10.0.0.2:22,
   • établir une correspondance en mémoire, d’une durée de vie limitée, entre ces données.
3. Quelques entrées de log plus tard, une autre chaîne d’exécution va :
   • détecter une attaque SSH depuis 10.0.0.1:12345 vers 10.0.0.2:22,
   • activer le remplacement (si correspondance trouvée) de la source, qui va remplacer 10.0.0.1:12345 par 12.34.56.78:23456
   • agir sur la vraie adresse IP de l’attaquant.

Effectivement je faisais référence à ton commentaire. Le fonctionnement que tu décris reste tout de même un peu limité…

J’utilise tilda car j’utilise toujours un terminal quand j’utilise le PC. Un appui de touche et il est là ; un autre appui et il s’en va (mais pas trop loin).

Une petite subtilité cependant : mon tilda est configuré pour n’avoir qu’un seul « onglet » (de 800×600 par défaut), aucune décoration de fenêtre, pas d’ascenseur ni historique et être semi-transparent ; bref : discret et me permettant de taper des commandes en distinguant ce qu’il y a dans le fenêtre derrière. Mais surtout, la commande est modifiée pour utiliser screen -AdRRU ou tmux new -ADsPC (j’utilise l’un ou l’autre selon le PC…).

Le second composant essentiel est donc le multiplexeur de terminal (screen ou tmux), qui prend en charge l’« ascenseur », la recherche dans ce dernier, le pavage, les « onglets », etc., sans oublier le maintien des commandes en cours quand la session utilisateur plante.
Il est fréquent que j’aie jusqu’à 6 onglets, et même un tmux par remote dans plusieurs onglets du tmux/screen local, avec dans chacun plusieurs onglets…

Et 1 cal = 4,18 J si mes souvenirs sont exacts. Donc 1 Wh = 3,6 kJ = 861 calories

Ce qui prouve, une fois de plus, que la consommation d’1 water ne fait pas grossir beaucoup :-p

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