Parce qu'on peut vouloir une base système d'une stabilité remarquable et des logiciels récents. C'est tout l'intérêt de la séparation système / applications utilisateur.
C'est pas faux.
Cela dit, je vais faire un gros raccourci à la truelle, mais je vois la séparation système/applis comme une Windowsification. La différence étant que, pour le moment, le système est suffisamment protégé des applications pour rester stable. Vu l'évolution toujours surpenante de systemd (tiens, en parlant de trucs plus ou moins imposés par Red Hat…), ça pourrait ne pas durer.
Je ne suis pas d'accord avec le « manifestement inadapté ». Je suis sous Linux depuis la RedHat 5.2. Je suis passé par Slackware, Mandrake, Gentoo (que j'ai adorée), Foresight, Ubuntu, Debian, Fedora, Arch et d'autres. La difficulté à installer un logiciel en-dehors du cadre prévu par la distribution a toujours été une plaie.
Ça ne me rajeunit pas non plus, tout ça.
La difficulté d'installation dépend aussi du logiciel et de la façon dont il a été développé, et, pour certains logiciels, ne dépend pas de la distrib choisie, on est d'accord là-dessus.
C'est vrai pour l'utilisateur, qui veut pouvoir utiliser la dernière version de son logiciel fétiche sans avoir à se demander si oui ou non elle est disponible pour son système, comme pour le développeur, qui n'a pas envie d'être tributaire des process de packaging des N distributions existantes, et encore moins de devoir tout se farcir lui-même.
En tant qu'utilisateur, pour des tests ou une utilisation ponctuelle, je passe par des VMs. Ça pose d'autres problèmes, mais ça résout celui de la compatibilité. Et si c'est pour une utilisation pérenne, n'ayant aucun logiciel "fétiche", je vois les choses différemment : soit ça s'installe et ça fonctionne, soit j'en trouve un autre. Soit, au pire, je scripte.
En tant qu'admin système/sécurité, la méthode conteneurs, c'est aussi sûr que le BYOD : quand on ne maîtrise plus rien, la question n'est pas de savoir si on va se faire poutrer, mais quand.
Pour les devs, n'ayant qu'une vision très partielle des relations entretenues avec les équipes de maintenance des distribs et des contraintes que ça impose, je ne peux que supposer que tu as raison, et je comprends tout-à-fait ce point de vue.
Une solution pertinente pour cela, c'est de se mettre d'accord sur un format cross-distribution de packaging d'applications. C'est, entre autres choses, ce que propose Flatpak.
Il est là, le problème.
Et je le comprends parfaitement. Gentoo, c'est super cool. Ma conjointe, elle, veut juste cliquer sur « installer Spotify ». Comme sur son téléphone.
La mienne a trouvé la commande magique pour que tout fonctionne : "CHÉÉÉÉÉÉRRRIIIIII !!!!!"
(attention, le nombre de points d'exclamation est important. Une erreur pour engendrer des problèmes de latences plus ou moins élevées :) )
Cela dit, pour son PC et ses besoins, Gentoo n'était pas la distrib la plus adaptée. Elle arrive à se débrouiller avec une LMDE, et l'admin est content qu'elle utilise un système stable, léger, et facile à entretenir.
Encore une fois, je parle ici plutôt d'utilisation desktop.
Je comprends.
Et je réagissais également à ce que tu disais quelques commentaires plus haut sur les magasins d'application. C'est à nuancer pour une utilisation serveur, bien que j'ajoute parfois des repos upstream sur mes AlmaLinux (notamment pour Docker).
Docker pour les serveurs, Flatpak pour les stations… Même principe, pour deux utilités différentes ?
L'intégration d'un logiciel dans un environnement précontraint, c'est justement le boulot des intégrateurs et des intégratrices.
Et là, on arrive à un autre problème de l'informatique en entreprise aujourd'hui : pour aller toujours plus vite, et en payant toujours moins cher, on a réduit la place de l'intégration, et on a inventé les devops.
Ça, c'est seulement si ton application est présente dans les repos, et seulement si elle l'est à la version souhaitée. Si ce n'est pas le cas, s'il faut passer par un repo tiers, pour peu par exemple qu'une version de lib soit incompatible, ça peut rapidement devenir l'horreur.
Dans ce cas, pourquoi choisir la branche stable de Debian ?
En desktop RPM, si on veut les versions récentes des logiciels courants, on installe une Fedora, pas une RHEL.
Tu parles ici d'une utilisation serveur. Et effectivement, sur mes serveurs de production, j'essaie au plus possible de me tenir aux repos officiels.
Une utilisation desktop n'a pas les mêmes impératifs.
Problème XY. Avant d'adapter un outil manifestement inadapté, mieux vaut se demander s'il n'existe pas un autre outil directement conçu pour ses besoins.
PC portable, avec tous les outils courants (suite bureautique, messagerie, navigateur, logiciels de lecture et d'édition multimedias), et de quoi faire tourner des VMs "maquettes". Lui aussi sous Gentoo, et lui aussi utilisé au quotidien.
Zéro Flatpak, Snap, Nix, et j'en passe. Et pourtant, dans les deux cas, il y a des logiciels installés depuis des overlays, ou hors dépôts, à partir des sources. L'avantage de Gentoo, là-dessus, c'est que les outils pour le faire sont installés par défaut. Et le passage par la case compilation, c'est long, mais ça évite de devoir installer trouze versions (avec les problèmes de sécurité afférents) de la même bibliothèque.
Je ne cherche pas ici à faire de la propagande pour une ou plusieurs distribs en particulier. J'ai juste décidé d'utiliser celles qui correspondent le mieux à mes besoins.
Même remarque. Le modèle "magasins (au pluriel…) d'applications" ne semble si désirable que ça à tout le monde. Et encore moins au point de l'imposer à toutes et à tous, et surtout pour de mauvaises raisons (économie de travail sur le dos des mainteneurs bénévoles ou des développeurs (bénévoles ou non) de logiciels tiers, dans le cas présent).
Après la conteneurisation, les paquets et les magasins virtuels. Dans les deux cas, plutôt que de s'appuyer sur un environnement logiciel existant, on préfère laisser les autres embarquer tout ce dont leurs logiciels ont besoin dans leurs propres bulles. Le moindre exécutable devient une enclume, et on perd ce qui fait justement la force des distribs, à savoir un ensemble logiciel léger, cohérent, facile à mettre à jour (pour les admins/utilisateurs), avec une gestion fine et transparente des dépendances.
Bref, "l'année du bureau Linux", c'est (toujours) pas pour demain ! :)
Et c'est bien dommage, étant donné que la fin du support de Windows 10 arrive à grands pas.
Mais là, on sort du monde de l'entreprise.
Après Canonical fait pareil
Je n'ai pas dit que l'herbe était plus verte ailleurs.
Personnellement, je ne suis pas fan d'Ubuntu non plus.
Et pour aller plus loin : est-ce que le travail d'empaqueteur et mainteneur d'applications de bureau ne ferait pas doublon avec les développeurs/éditeurs qui peuvent maintenant fournir des binaires directement aux utilisateurs via Flatpak ?
Peuvent. Pas "doivent".
Encore une fois, Red Hat est en train d'imposer sa vision de GNU/linux au reste du monde.
L’objectif est d’abord de réduire la charge de maintenance en limitant le nombre de paquets que Red Hat doit maintenir tout au long du cycle de vie de la distribution en reportant cette tâche sur les bénévoles d’EPEL
Ah.
Vu le prix de la licence RHEL, on pourrait (mais y'a p'têt qu'à moi que ça le fait ?) trouver cette décision (et la façon dont elle est présentée) un poil déplacée.
Et si j'étais taquin, j'ajouterais que si Red Hat se sent obligé de, hem…, "reporter" cette charge de travail sur d'autres, ça pourrait avoir un tout petit rapport avec une récente vague de licenciements dans l'entreprise, à un moment où, pourtant, ladite entreprise se porte comme un charme.
Si.
Mais ce n'est pas mon genre.
Je comprends les angoisses de l'auteur. Tout le monde devrait les comprendre.
D'ailleurs, tout le monde devrait considérer qu'un support de stockage peut tomber en rade à tout moment.
Et c'est pour ça qu'on fait des sauvegardes.
Comme on dit dans les milieux autorisés, il y a deux types d'utilisateurs : ceux qui font régulièrement leurs sauvegardes, et ceux qui n'ont jamais perdu de données.
Pour moi, S.M.A.R.T. ne sert qu'à anticiper la perte d'un disque. Quand l'alerte se déclenche, il est temps d'acquérir un disque de remplacement.
Pour moi, badblocks ne sert qu'à une seule chose : renvoyer un nouveau disque défectueux à son vendeur pour échange ou remboursement.
Dans tous les cas, 1 (un) seul bloc défectueux, c'est déjà trop, le disque est déjà mort. Le nombre ne peut qu'augmenter, ça augmente vite, et plus ça augmente, et plus ça augmente vite.
Oui j'appelle cela une version "gratuite", le terme exact est il me semble "shareware avec période d'essai gratuite éternelle".
Non, c'est une licence "OEM". Elle est bien payante (environ 50 €, inclus dans l'achat de l'ordinateur) et limitée (en l'occurrence, elle est liée au PC acheté). Rien à voir, vraiment pas, avec un shareware.
Ce qui veut dire, que 1/ si le contrat de licence est rompu (installation sur une autre machine que celle prévue), Microsoft peut révoquer la licence à tout moment, et est dans son bon droit pour ce faire, et 2/ la licence est remboursable, si elle n'a jamais été activée. Selon les constructeurs, c'est plus ou moins facile, voire quasi-impossible, mais, comme c'est de la vente liée, il est tout-à-fait possible de porter plainte contre les constructeurs récalcitrants si on est motivé pour aller jusqu'au tribunal.
Pour une VM de test, il existe des licences temporaires et gratuites.
Eh bien, ça en fait, des logiciels de compta.
Étant adepte des logiciels "appli web", je testerais bien Smoothie Funds en auto-hébergement… D'ailleurs, est-il possible d'ajouter le lien du dépôt Git dans la dépêche ? C'est là, je crois : https://github.com/tjustino/smoothie_funds
Sinon, j'utilise Firefly III, un logiciel web en PHP, compatible PostgreSQL (entre autres), en auto-hébergement. J'en suis content, même s'il a quelques faiblesses : impossible d'utiliser plusieurs identifiants pour une même instance (pour un compte joint, par exemple, tout le monde doit utiliser le même login/mot de passe), et, avec une base PostgreSQL, les recherches dont sensibles à la casse, ce qui peut vite devenir pénible.
Visiblement, j'ai abordé un sujet polémique. Et pas un vendredi, en plus. Oups.
Mais bon, même je comprends les problèmes que gUI et toi exposez, là, on parle juste d'un pare-feu perso pour une dizaine de proches.
Ben oui, ça filtre une grosse partie du trafic. C'est toujours ça de moins à gérer.
Et le cousin en Chine, ben il aura droit à son exception. Et ça n'empêchera pas de continuer à bloquer les adresses nigériannes, vietnamiennes, péruviennes, luxembourgeoises…
Admettons qu'en temps normal, je bloque les adresses IP espagnoles. Et tant qu'aucun de mes utilisateurs ne s'en plaint, j'ose croire que c'est bien comme ça. Par contre, quand j'ai prévu de me déplacer en Espagne, je débloque juste avant, et je rebloque en rentrant, et j'ai limité la surface d'attaque le reste du temps. Où est le problème ?
Et puis, certes, ce n'est pas parfait, mais il est bien évidemment hors de question de ne se reposer que sur un seul outil de sécurité. Le bot nmap, par exemple, il doit aussi être bloqué par d'autres règles ou mécanismes, qu'il soit français ou non. Mais comme ces mécanismes sont potentiellement un peu plus gourmands, autant faire un tri au préalable, non ?
1/ Le contexte est important. Le filtrage geoip me semble pertinent en utilisation à titre personnel, pour un cercle de proches, beaucoup moins pour un site commercial ou gouvernemental. Il y a quand même un gros paquet de différences entre une instance nextcloud auto-hébergée et les sites de la DGFIP…
2/ Là, on touche aux problèmes des bases d'adresses IP, et de la fréquence de leur mise à jour. Et comme elles sont, de surcroît, de moins en moins librement accessibles, ça ne risque pas de s'arranger, malheureusement.
C'est une approche un peu différente de ce que j'ai l'habitude de voir. Et rien que pour ça, ça mérite d'être creusé.
Il ne faut pas oublier que la sécurité, c'est comme un oignon : c'est construit en plusieurs couches superposées. Et plus il y en a, mieux c'est. :)
j’héberge mes services à la maison au frais dans le garage sur un serveur physique, des VMs et depuis peu des instances cloud. Moi, ma petite famille et un cercle d’amis en sont les seuls utilisateurs.
La première des restrictions IP devrait donc être géographique. Sans vouloir verser dans le cliché, à moins d'avoir des amis chinois ou russes, inutile de laisser passer les adresses IP de ces pays. Du coup, ce serait peut-être intéressant de rajouter un module basé sur xtables geoip, par exemple.
N’étant pas à l’abri de louper une mise à jour de temps en temps,
D'où la sécurité par couches superposées. ;)
cela s’installe en 5 minutes via docker-compose (oui, c’est un peu vendeur,
Pas pour moi. Les conteneurs, c'est devenu la solution de facilité, qui masque le problème de la gestion des dépendances. Pour beaucoup, c'est facile, donc on ne fait même plus gaffe à ce qu'on installe. Résultat, l'admin n'est plus vraiment maître de ce qui tourne sur ses bécanes, ce que je trouve un peu embêtant quand, justement, on parle de garder la main sur ses données…
Bref, si tu pouvais proposer une méthode d'utilisation sans docker, ça serait cool. :)
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . En réponse à la dépêche Sortie de CentOS Stream 10. Évalué à 2. Dernière modification le 20 décembre 2024 à 18:05.
C'est pas faux.
Cela dit, je vais faire un gros raccourci à la truelle, mais je vois la séparation système/applis comme une Windowsification. La différence étant que, pour le moment, le système est suffisamment protégé des applications pour rester stable. Vu l'évolution toujours surpenante de systemd (tiens, en parlant de trucs plus ou moins imposés par Red Hat…), ça pourrait ne pas durer.
Ça ne me rajeunit pas non plus, tout ça.
La difficulté d'installation dépend aussi du logiciel et de la façon dont il a été développé, et, pour certains logiciels, ne dépend pas de la distrib choisie, on est d'accord là-dessus.
En tant qu'utilisateur, pour des tests ou une utilisation ponctuelle, je passe par des VMs. Ça pose d'autres problèmes, mais ça résout celui de la compatibilité. Et si c'est pour une utilisation pérenne, n'ayant aucun logiciel "fétiche", je vois les choses différemment : soit ça s'installe et ça fonctionne, soit j'en trouve un autre. Soit, au pire, je scripte.
En tant qu'admin système/sécurité, la méthode conteneurs, c'est aussi sûr que le BYOD : quand on ne maîtrise plus rien, la question n'est pas de savoir si on va se faire poutrer, mais quand.
Pour les devs, n'ayant qu'une vision très partielle des relations entretenues avec les équipes de maintenance des distribs et des contraintes que ça impose, je ne peux que supposer que tu as raison, et je comprends tout-à-fait ce point de vue.
Il est là, le problème.
La mienne a trouvé la commande magique pour que tout fonctionne : "CHÉÉÉÉÉÉRRRIIIIII !!!!!"
(attention, le nombre de points d'exclamation est important. Une erreur pour engendrer des problèmes de latences plus ou moins élevées :) )
Cela dit, pour son PC et ses besoins, Gentoo n'était pas la distrib la plus adaptée. Elle arrive à se débrouiller avec une LMDE, et l'admin est content qu'elle utilise un système stable, léger, et facile à entretenir.
Je comprends.
Docker pour les serveurs, Flatpak pour les stations… Même principe, pour deux utilités différentes ?
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . En réponse à la dépêche Sortie de CentOS Stream 10. Évalué à 4.
L'intégration d'un logiciel dans un environnement précontraint, c'est justement le boulot des intégrateurs et des intégratrices.
Et là, on arrive à un autre problème de l'informatique en entreprise aujourd'hui : pour aller toujours plus vite, et en payant toujours moins cher, on a réduit la place de l'intégration, et on a inventé les devops.
Je sais, je sais, je suis devenu un vieux con.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . En réponse à la dépêche Sortie de CentOS Stream 10. Évalué à 3.
Dans ce cas, pourquoi choisir la branche stable de Debian ?
En desktop RPM, si on veut les versions récentes des logiciels courants, on installe une Fedora, pas une RHEL.
Problème XY. Avant d'adapter un outil manifestement inadapté, mieux vaut se demander s'il n'existe pas un autre outil directement conçu pour ses besoins.
Station multimedia, kodi + divers lecteurs (audio, images, vidéo, documents divers…), navigateur web, utilisation quotidienne. Également sous Gentoo.
PC portable, avec tous les outils courants (suite bureautique, messagerie, navigateur, logiciels de lecture et d'édition multimedias), et de quoi faire tourner des VMs "maquettes". Lui aussi sous Gentoo, et lui aussi utilisé au quotidien.
Zéro Flatpak, Snap, Nix, et j'en passe. Et pourtant, dans les deux cas, il y a des logiciels installés depuis des overlays, ou hors dépôts, à partir des sources. L'avantage de Gentoo, là-dessus, c'est que les outils pour le faire sont installés par défaut. Et le passage par la case compilation, c'est long, mais ça évite de devoir installer trouze versions (avec les problèmes de sécurité afférents) de la même bibliothèque.
Je ne cherche pas ici à faire de la propagande pour une ou plusieurs distribs en particulier. J'ai juste décidé d'utiliser celles qui correspondent le mieux à mes besoins.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . En réponse à la dépêche Sortie de CentOS Stream 10. Évalué à 0.
Ou antiX. Sur base Debian, d'ailleurs.
L'enfer ?
apt update && apt full-upgrade. Reboot si mise à jour noyal. Fin.
Serveur web + PHP + instance java + bases PostgreSQL + caches Redis.
Sous Gentoo. Les régressions et les mises à jour pénibles, c'est bon, je connais.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . En réponse à la dépêche Sortie de CentOS Stream 10. Évalué à 2.
Même remarque. Le modèle "magasins (au pluriel…) d'applications" ne semble si désirable que ça à tout le monde. Et encore moins au point de l'imposer à toutes et à tous, et surtout pour de mauvaises raisons (économie de travail sur le dos des mainteneurs bénévoles ou des développeurs (bénévoles ou non) de logiciels tiers, dans le cas présent).
Après la conteneurisation, les paquets et les magasins virtuels. Dans les deux cas, plutôt que de s'appuyer sur un environnement logiciel existant, on préfère laisser les autres embarquer tout ce dont leurs logiciels ont besoin dans leurs propres bulles. Le moindre exécutable devient une enclume, et on perd ce qui fait justement la force des distribs, à savoir un ensemble logiciel léger, cohérent, facile à mettre à jour (pour les admins/utilisateurs), avec une gestion fine et transparente des dépendances.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . En réponse à la dépêche Sortie de CentOS Stream 10. Évalué à 1.
Et c'est bien dommage, étant donné que la fin du support de Windows 10 arrive à grands pas.
Mais là, on sort du monde de l'entreprise.
Je n'ai pas dit que l'herbe était plus verte ailleurs.
Personnellement, je ne suis pas fan d'Ubuntu non plus.
Peuvent. Pas "doivent".
Encore une fois, Red Hat est en train d'imposer sa vision de GNU/linux au reste du monde.
# Une pensée émue pour les bénévoles...
Posté par Lenbootil . En réponse à la dépêche Sortie de CentOS Stream 10. Évalué à 10.
Ah.
Vu le prix de la licence RHEL, on pourrait (mais y'a p'têt qu'à moi que ça le fait ?) trouver cette décision (et la façon dont elle est présentée) un poil déplacée.
Et si j'étais taquin, j'ajouterais que si Red Hat se sent obligé de, hem…, "reporter" cette charge de travail sur d'autres, ça pourrait avoir un tout petit rapport avec une récente vague de licenciements dans l'entreprise, à un moment où, pourtant, ladite entreprise se porte comme un charme.
Si.
Mais ce n'est pas mon genre.
# Sau-ve-gar-des !
Posté par Lenbootil . En réponse à la dépêche S.M.A.R.T. badblocks badblocks2. Évalué à 6.
Je comprends les angoisses de l'auteur. Tout le monde devrait les comprendre.
D'ailleurs, tout le monde devrait considérer qu'un support de stockage peut tomber en rade à tout moment.
Et c'est pour ça qu'on fait des sauvegardes.
Comme on dit dans les milieux autorisés, il y a deux types d'utilisateurs : ceux qui font régulièrement leurs sauvegardes, et ceux qui n'ont jamais perdu de données.
Pour moi, S.M.A.R.T. ne sert qu'à anticiper la perte d'un disque. Quand l'alerte se déclenche, il est temps d'acquérir un disque de remplacement.
Pour moi, badblocks ne sert qu'à une seule chose : renvoyer un nouveau disque défectueux à son vendeur pour échange ou remboursement.
Dans tous les cas, 1 (un) seul bloc défectueux, c'est déjà trop, le disque est déjà mort. Le nombre ne peut qu'augmenter, ça augmente vite, et plus ça augmente, et plus ça augmente vite.
# Déjà vendredi ?
Posté par Lenbootil . En réponse à la dépêche Systemd v256. Évalué à 4.
Ah ben non.
[^] # Re: A quoi servent les licences Windows ?
Posté par Lenbootil . En réponse à la dépêche Transférer sa licence Windows dans une VM. Évalué à 3.
Non, c'est une licence "OEM". Elle est bien payante (environ 50 €, inclus dans l'achat de l'ordinateur) et limitée (en l'occurrence, elle est liée au PC acheté). Rien à voir, vraiment pas, avec un shareware.
Ce qui veut dire, que 1/ si le contrat de licence est rompu (installation sur une autre machine que celle prévue), Microsoft peut révoquer la licence à tout moment, et est dans son bon droit pour ce faire, et 2/ la licence est remboursable, si elle n'a jamais été activée. Selon les constructeurs, c'est plus ou moins facile, voire quasi-impossible, mais, comme c'est de la vente liée, il est tout-à-fait possible de porter plainte contre les constructeurs récalcitrants si on est motivé pour aller jusqu'au tribunal.
Pour une VM de test, il existe des licences temporaires et gratuites.
# Firefly III
Posté par Lenbootil . En réponse à la dépêche Logiciels libres de finances personnelles. Évalué à 3.
Eh bien, ça en fait, des logiciels de compta.
Étant adepte des logiciels "appli web", je testerais bien Smoothie Funds en auto-hébergement… D'ailleurs, est-il possible d'ajouter le lien du dépôt Git dans la dépêche ? C'est là, je crois : https://github.com/tjustino/smoothie_funds
Sinon, j'utilise Firefly III, un logiciel web en PHP, compatible PostgreSQL (entre autres), en auto-hébergement. J'en suis content, même s'il a quelques faiblesses : impossible d'utiliser plusieurs identifiants pour une même instance (pour un compte joint, par exemple, tout le monde doit utiliser le même login/mot de passe), et, avec une base PostgreSQL, les recherches dont sensibles à la casse, ce qui peut vite devenir pénible.
[^] # Re: Intéressant
Posté par Lenbootil . En réponse à la dépêche MySafeIP: un tiers de confiance pour votre pare-feu !. Évalué à 1.
Oui, j'ai vu. Merci pour le lien, cela dit.
Je disais juste qu'une ou deux lignes d'information dans le README, ça pourrait aussi être une bonne idée.
[^] # Re: Intéressant
Posté par Lenbootil . En réponse à la dépêche MySafeIP: un tiers de confiance pour votre pare-feu !. Évalué à 3.
Visiblement, j'ai abordé un sujet polémique. Et pas un vendredi, en plus. Oups.
Mais bon, même je comprends les problèmes que gUI et toi exposez, là, on parle juste d'un pare-feu perso pour une dizaine de proches.
Ben oui, ça filtre une grosse partie du trafic. C'est toujours ça de moins à gérer.
Et le cousin en Chine, ben il aura droit à son exception. Et ça n'empêchera pas de continuer à bloquer les adresses nigériannes, vietnamiennes, péruviennes, luxembourgeoises…
Admettons qu'en temps normal, je bloque les adresses IP espagnoles. Et tant qu'aucun de mes utilisateurs ne s'en plaint, j'ose croire que c'est bien comme ça. Par contre, quand j'ai prévu de me déplacer en Espagne, je débloque juste avant, et je rebloque en rentrant, et j'ai limité la surface d'attaque le reste du temps. Où est le problème ?
Et puis, certes, ce n'est pas parfait, mais il est bien évidemment hors de question de ne se reposer que sur un seul outil de sécurité. Le bot nmap, par exemple, il doit aussi être bloqué par d'autres règles ou mécanismes, qu'il soit français ou non. Mais comme ces mécanismes sont potentiellement un peu plus gourmands, autant faire un tri au préalable, non ?
[^] # Re: Intéressant
Posté par Lenbootil . En réponse à la dépêche MySafeIP: un tiers de confiance pour votre pare-feu !. Évalué à 3.
Ah oui, pas de bol. Et pas cool, non plus.
Mais…
1/ Le contexte est important. Le filtrage geoip me semble pertinent en utilisation à titre personnel, pour un cercle de proches, beaucoup moins pour un site commercial ou gouvernemental. Il y a quand même un gros paquet de différences entre une instance nextcloud auto-hébergée et les sites de la DGFIP…
2/ Là, on touche aux problèmes des bases d'adresses IP, et de la fréquence de leur mise à jour. Et comme elles sont, de surcroît, de moins en moins librement accessibles, ça ne risque pas de s'arranger, malheureusement.
# Intéressant
Posté par Lenbootil . En réponse à la dépêche MySafeIP: un tiers de confiance pour votre pare-feu !. Évalué à 4.
C'est une approche un peu différente de ce que j'ai l'habitude de voir. Et rien que pour ça, ça mérite d'être creusé.
Il ne faut pas oublier que la sécurité, c'est comme un oignon : c'est construit en plusieurs couches superposées. Et plus il y en a, mieux c'est. :)
La première des restrictions IP devrait donc être géographique. Sans vouloir verser dans le cliché, à moins d'avoir des amis chinois ou russes, inutile de laisser passer les adresses IP de ces pays. Du coup, ce serait peut-être intéressant de rajouter un module basé sur xtables geoip, par exemple.
D'où la sécurité par couches superposées. ;)
Pas pour moi. Les conteneurs, c'est devenu la solution de facilité, qui masque le problème de la gestion des dépendances. Pour beaucoup, c'est facile, donc on ne fait même plus gaffe à ce qu'on installe. Résultat, l'admin n'est plus vraiment maître de ce qui tourne sur ses bécanes, ce que je trouve un peu embêtant quand, justement, on parle de garder la main sur ses données…
Bref, si tu pouvais proposer une méthode d'utilisation sans docker, ça serait cool. :)