Ubuntu 18.04 et partitions

Marc SCHAEFER

11/05/2018 à 08:51

Salut,
tout d'abord, je n'ai aucune expérience avec Ubuntu (je préfère Debian) et
encore moins avec snap, donc peut-être attends d'autres conseils de personnes
plus avisées!
Dominique wrote:

core 16-2.32.6 4571 stable canonical core

Celui-là me titille, je me demande à quoi il sert.
https://www.ubuntu.com/core
à voir c'est juste un conteneur probablement utilisé pour
créer d'autres conteneurs pour faire des trucs sans risquer
de saboter l'OS de base.
Donc supprimable aussi.

gnome-3-26-1604 3.26.0 64 stable/? canonical -
gnome-calculator 3.28.1 167 stable/? canonical -
gnome-characters 3.28.0 86 stable/? canonical -
gnome-logs 3.28.0 31 stable/? canonical -
gnome-system-monitor 3.26.0 39 stable/? canonical -

Ceux-là me semblent supprimables sans risque.

Dominique

12/05/2018 à 06:27

Le 11/05/2018 à 08:51, Marc SCHAEFER a écrit :

Salut,
tout d'abord, je n'ai aucune expérience avec Ubuntu (je préfère Debian) et
encore moins avec snap, donc peut-être attends d'autres conseils de personnes
plus avisées!

Je te remercie pour ton retour. À dire vrai, ma question était de pure
curiosité. Je ne vais pas courir le risque de tout casser. Finalement,
mon kubuntu fonctionne très bien.
Bonne journée,
--
Dominique
Courriel : dominique point sextant ate orange en France
Esto quod es

Doug713705

13/05/2018 à 10:36

Le 10-05-2018, Eric Masson nous expliquait dans
fr.comp.os.linux.configuration () :

Doug713705 writes:
'Lut,
Il y probablement un confinement mais il existe aussi existera encore des
failes qui permettent de sortir de ces confinements mais ce n'est pas
trop le repoche que je fais à cet approche.

Pas plus que de failles noyau permettant de compromettre globalement un
système.

Pas moins non plus.

Pour moi ce types de paquets livrés avec leurs versions de libs va
totalement à l'encontre du principe de bibliothèques partagées avec les
problèmatiques qui vont avec.

Comme casser une appli parce qu'une dépendance a été mise à jour par le
gestionnaire de paquets lors d'une opération sur une autre appli ?

Mauvais gestionnaire de paquets, changer gestionnaire de paquets.

Dans certains cas, l'isolation d'applications et de leurs dépendances
est une solution tout à fait valide (au pif, utilisation d'une version
expérimentale d'une lib par une application donnée sans avoir à se baser
sur un mécanisme de version de libs, s'il existe, ou encore couplé à des
snapshots du fs, une possibilité de RAZ de l'application complète dans
un état connu sans impact sur les autres applis installées).

Tout ceci est possible grace à la virtualisation sans passer par la
containerisation.

Bref, dans une certaine mesure on s'approche d'un système à la Windows
(plutôt Mac en fait) reniant un principe de plus de ceux qui ont fait le
succès des *nix.

Cela ne renie rien puisque c'est construit sur ces bases, cela ajoute
juste une possibilité supplémentaire d'empaquetage des applications
correspondant à un besoin particulier.

Ok pour ça mais qui de la réalité de la chaine de confiance de ces
paquets ?
Dans une grande majorité de cas que j'ai pu voir, c'est toujours un
foutoir dès qu'on essaie de tracer l'origine exacte des libs fournies.
Il n'est pas rare d'en trouver d'origines obscures simplement
empaquetées par le dev qui a trouver la solution à son problème en
téléchargeant depuis un site improbable une lib qui résoud ses
problématiques mais qui potentiellement ouvre un peu trop grand les
portes.

On a là le térreau idéal pour avoir des systèmes mal/partiellement mis
à jour. C'est surtout ça mon point.

C'est déjà le cas, le nombre de systèmes en production qui ne voient
plus de màj pour éviter des régressions fonctionnelles est tout sauf
négligeable.

C'est vrai mais la containerisation ajoute une raison supplémentaire de
ne pas (bien) mettre à jour.
Tout ça n'améliore en rien la securité, dire le contraire est mensonge.
C'était mon point.
--
À toujours vouloir être ailleurs,
Pyromanes de nos têtes brûlées,
On confond les batt'ments du c½ur
Avec nos diesels encrassés.
-- H.F. Thiéfaine, Errer humanum est

Le 10-05-2018, Eric Masson nous expliquait dans
fr.comp.os.linux.configuration (<ovidse-k11.ln1@srvbsdfenssv.interne.associated-bears.org>) :

Doug713705 <doug.letough@free.fr> writes:

'Lut,

Il y probablement un confinement mais il existe aussi existera encore des
failes qui permettent de sortir de ces confinements mais ce n'est pas
trop le repoche que je fais à cet approche.

Pas plus que de failles noyau permettant de compromettre globalement un
système.

Pas moins non plus.

Pour moi ce types de paquets livrés avec leurs versions de libs va
totalement à l'encontre du principe de bibliothèques partagées avec les
problèmatiques qui vont avec.

Comme casser une appli parce qu'une dépendance a été mise à jour par le
gestionnaire de paquets lors d'une opération sur une autre appli ?

Mauvais gestionnaire de paquets, changer gestionnaire de paquets.

Dans certains cas, l'isolation d'applications et de leurs dépendances
est une solution tout à fait valide (au pif, utilisation d'une version
expérimentale d'une lib par une application donnée sans avoir à se baser
sur un mécanisme de version de libs, s'il existe, ou encore couplé à des
snapshots du fs, une possibilité de RAZ de l'application complète dans
un état connu sans impact sur les autres applis installées).

Tout ceci est possible grace à la virtualisation sans passer par la
containerisation.

Bref, dans une certaine mesure on s'approche d'un système à la Windows
(plutôt Mac en fait) reniant un principe de plus de ceux qui ont fait le
succès des *nix.

Cela ne renie rien puisque c'est construit sur ces bases, cela ajoute
juste une possibilité supplémentaire d'empaquetage des applications
correspondant à un besoin particulier.

Ok pour ça mais qui de la réalité de la chaine de confiance de ces
paquets ?
Dans une grande majorité de cas que j'ai pu voir, c'est toujours un
foutoir dès qu'on essaie de tracer l'origine exacte des libs fournies.
Il n'est pas rare d'en trouver d'origines obscures simplement
empaquetées par le dev qui a trouver la solution à son problème en
téléchargeant depuis un site improbable une lib qui résoud ses
problématiques mais qui potentiellement ouvre un peu trop grand les
portes.

On a là le térreau idéal pour avoir des systèmes mal/partiellement mis
à jour. C'est surtout ça mon point.

C'est déjà le cas, le nombre de systèmes en production qui ne voient
plus de màj pour éviter des régressions fonctionnelles est tout sauf
négligeable.

C'est vrai mais la containerisation ajoute une raison supplémentaire de
ne pas (bien) mettre à jour.

Tout ça n'améliore en rien la securité, dire le contraire est mensonge.
C'était mon point.

--
À toujours vouloir être ailleurs,
Pyromanes de nos têtes brûlées,
On confond les batt'ments du c½ur
Avec nos diesels encrassés.
-- H.F. Thiéfaine, Errer humanum est

Vous avez filtré cet utilisateur ! Consultez son message

Le 10-05-2018, Eric Masson nous expliquait dans
fr.comp.os.linux.configuration () :

Doug713705 writes:
'Lut,
Il y probablement un confinement mais il existe aussi existera encore des
failes qui permettent de sortir de ces confinements mais ce n'est pas
trop le repoche que je fais à cet approche.

Pas plus que de failles noyau permettant de compromettre globalement un
système.

Pas moins non plus.

Pour moi ce types de paquets livrés avec leurs versions de libs va
totalement à l'encontre du principe de bibliothèques partagées avec les
problèmatiques qui vont avec.

Comme casser une appli parce qu'une dépendance a été mise à jour par le
gestionnaire de paquets lors d'une opération sur une autre appli ?

Mauvais gestionnaire de paquets, changer gestionnaire de paquets.

Dans certains cas, l'isolation d'applications et de leurs dépendances
est une solution tout à fait valide (au pif, utilisation d'une version
expérimentale d'une lib par une application donnée sans avoir à se baser
sur un mécanisme de version de libs, s'il existe, ou encore couplé à des
snapshots du fs, une possibilité de RAZ de l'application complète dans
un état connu sans impact sur les autres applis installées).

Tout ceci est possible grace à la virtualisation sans passer par la
containerisation.

Bref, dans une certaine mesure on s'approche d'un système à la Windows
(plutôt Mac en fait) reniant un principe de plus de ceux qui ont fait le
succès des *nix.

Cela ne renie rien puisque c'est construit sur ces bases, cela ajoute
juste une possibilité supplémentaire d'empaquetage des applications
correspondant à un besoin particulier.

Ok pour ça mais qui de la réalité de la chaine de confiance de ces
paquets ?
Dans une grande majorité de cas que j'ai pu voir, c'est toujours un
foutoir dès qu'on essaie de tracer l'origine exacte des libs fournies.
Il n'est pas rare d'en trouver d'origines obscures simplement
empaquetées par le dev qui a trouver la solution à son problème en
téléchargeant depuis un site improbable une lib qui résoud ses
problématiques mais qui potentiellement ouvre un peu trop grand les
portes.

On a là le térreau idéal pour avoir des systèmes mal/partiellement mis
à jour. C'est surtout ça mon point.

C'est déjà le cas, le nombre de systèmes en production qui ne voient
plus de màj pour éviter des régressions fonctionnelles est tout sauf
négligeable.

C'est vrai mais la containerisation ajoute une raison supplémentaire de
ne pas (bien) mettre à jour.
Tout ça n'améliore en rien la securité, dire le contraire est mensonge.
C'était mon point.
--
À toujours vouloir être ailleurs,
Pyromanes de nos têtes brûlées,
On confond les batt'ments du c½ur
Avec nos diesels encrassés.
-- H.F. Thiéfaine, Errer humanum est

Doug713705

13/05/2018 à 10:55

Le 10-05-2018, Marc SCHAEFER nous expliquait dans
fr.comp.os.linux.configuration (<pd17n7$1pd$) :

Il y probablement un confinement mais il existe aussi existera encore des
failes qui permettent de sortir de ces confinements mais ce n'est pas
trop le repoche que je fais à cet approche.

Juste; vrai pour toutes les formes de virtualisation et de confinement.
Pour moi ce types de paquets livrés avec leurs versions de libs va
totalement à l'encontre du principe de bibliothèques partagées avec les
problèmatiques qui vont avec.

Totalement! C'est aller dans le sens contraire des bijoux que sont
les packages Debian, par exemple.
Mais, en informatique, on voit souvent que les meilleures solutions
sont remplacées par les solutions qui sont le plus facilement
gérables avec du personnel sans compétence.

Si ce n'était qu'en informtique cela serait supportable ;-)
C'est le pendant malheureux de l'automatisation et du progès d'une
manière générale. Il n'est plus nécessaire de comprendre les basses couches
pour manipuler des machines/services qui auraient demandé des savoirs
difficiles à acquerir à la génération antérieure.
Dans la plupart des cas tout cela permet à un plus grand nombre de
pouvoir intervenir sur ces systèmes sauf dans les cas où l'état du
système est en dehors des cas prévus par le manuel (ce qui ne manque
jamais d'arriver ;-))
C'est là que les "spécialistes" ou les "experts" interviennent.
Ces "esperts" sont simplement des personnes qui ont pris le temps
d'éétudier un peu plus en profondeur le système plutôt que de se
contenter des bêtes instructions à suivres détaillées sur une procédure
trop souvent obsolète et/ou corrigées à la rache au fil des versions par
des personnes n'ayant pas suffisamment d'historique pour comprendre
l'intégralité des implications de leurs modifications.
Quand on en est là, on n'est plus très loin de la catastrophe :)

Par exemple, imaginons un constructeur informatique comme HP:
est-il mieux qu'il fassent eux-mêmes des packages Debian de merde, ou des
packages snap un peu confinés ? La réponse parfaite est: "ils devraient
publier leurs interfaces en open-source et laisser les développeurs
Debian faire de jolis packages". Dans les faits, ils vont se
ruer sur snap (?).
Exemple: j'ai une fois installé un serveur HP, et ils proposaient
des packages Debian pour leur outils de monitoring (leur interface,
à l'époque, était différente des autres constructeurs, différente
de celle supportée par Debian en natif, donc). J'ai regardé le
package et j'ai vu assez vite le risque de rm -rf /$install_dir
avec une variable $install_dir pouvant dans certains cas être
vides ... j'ai essayé de reporter l'erreur, mais je me suis perdu
sur le site web d'HP.

Réfléchir c'est déjà désobéïr !
Outrecuidant et mécréant sysadmin qui ose lire, vérifier et comprendre
ce qu'on lui demande de faire plutôt qu'exécuter une procédure sainte
respectée par tous et qui n'a d'égales en pureté que les tables de la lois :)

Avec des zillions de paquets installés de cette manière il n'y a plus
vraiment moyen de s'assurer de la mise à jour des versions de libs pour
l'ensemble du système et des applications.

Clairement.
Et il y a aussi un impact de gaspillage mémoire.
On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à
jour. C'est surtout ça mon point.

Parfaitement d'accord.

Nous sommes malheureusement minoritaires :-/
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

Le 10-05-2018, Marc SCHAEFER nous expliquait dans
fr.comp.os.linux.configuration (<pd17n7$1pd$1@shakotay.alphanet.ch>) :

Il y probablement un confinement mais il existe aussi existera encore des
failes qui permettent de sortir de ces confinements mais ce n'est pas
trop le repoche que je fais à cet approche.

Juste; vrai pour toutes les formes de virtualisation et de confinement.

Pour moi ce types de paquets livrés avec leurs versions de libs va
totalement à l'encontre du principe de bibliothèques partagées avec les
problèmatiques qui vont avec.

Totalement! C'est aller dans le sens contraire des bijoux que sont
les packages Debian, par exemple.

Mais, en informatique, on voit souvent que les meilleures solutions
sont remplacées par les solutions qui sont le plus facilement
gérables avec du personnel sans compétence.

Si ce n'était qu'en informtique cela serait supportable ;-)

C'est le pendant malheureux de l'automatisation et du progès d'une
manière générale. Il n'est plus nécessaire de comprendre les basses couches
pour manipuler des machines/services qui auraient demandé des savoirs
difficiles à acquerir à la génération antérieure.

Dans la plupart des cas tout cela permet à un plus grand nombre de
pouvoir intervenir sur ces systèmes sauf dans les cas où l'état du
système est en dehors des cas prévus par le manuel (ce qui ne manque
jamais d'arriver ;-))

C'est là que les "spécialistes" ou les "experts" interviennent.
Ces "esperts" sont simplement des personnes qui ont pris le temps
d'éétudier un peu plus en profondeur le système plutôt que de se
contenter des bêtes instructions à suivres détaillées sur une procédure
trop souvent obsolète et/ou corrigées à la rache au fil des versions par
des personnes n'ayant pas suffisamment d'historique pour comprendre
l'intégralité des implications de leurs modifications.

Quand on en est là, on n'est plus très loin de la catastrophe :)

Par exemple, imaginons un constructeur informatique comme HP:
est-il mieux qu'il fassent eux-mêmes des packages Debian de merde, ou des
packages snap un peu confinés ? La réponse parfaite est: "ils devraient
publier leurs interfaces en open-source et laisser les développeurs
Debian faire de jolis packages". Dans les faits, ils vont se
ruer sur snap (?).

Exemple: j'ai une fois installé un serveur HP, et ils proposaient
des packages Debian pour leur outils de monitoring (leur interface,
à l'époque, était différente des autres constructeurs, différente
de celle supportée par Debian en natif, donc). J'ai regardé le
package et j'ai vu assez vite le risque de rm -rf /$install_dir
avec une variable $install_dir pouvant dans certains cas être
vides ... j'ai essayé de reporter l'erreur, mais je me suis perdu
sur le site web d'HP.

Réfléchir c'est déjà désobéïr !

Outrecuidant et mécréant sysadmin qui ose lire, vérifier et comprendre
ce qu'on lui demande de faire plutôt qu'exécuter une procédure sainte
respectée par tous et qui n'a d'égales en pureté que les tables de la lois :)

Avec des zillions de paquets installés de cette manière il n'y a plus
vraiment moyen de s'assurer de la mise à jour des versions de libs pour
l'ensemble du système et des applications.

Clairement.
Et il y a aussi un impact de gaspillage mémoire.

On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à
jour. C'est surtout ça mon point.

Parfaitement d'accord.

Nous sommes malheureusement minoritaires :-/

--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

Vous avez filtré cet utilisateur ! Consultez son message

Le 10-05-2018, Marc SCHAEFER nous expliquait dans
fr.comp.os.linux.configuration (<pd17n7$1pd$) :

Il y probablement un confinement mais il existe aussi existera encore des
failes qui permettent de sortir de ces confinements mais ce n'est pas
trop le repoche que je fais à cet approche.

Juste; vrai pour toutes les formes de virtualisation et de confinement.
Pour moi ce types de paquets livrés avec leurs versions de libs va
totalement à l'encontre du principe de bibliothèques partagées avec les
problèmatiques qui vont avec.

Totalement! C'est aller dans le sens contraire des bijoux que sont
les packages Debian, par exemple.
Mais, en informatique, on voit souvent que les meilleures solutions
sont remplacées par les solutions qui sont le plus facilement
gérables avec du personnel sans compétence.

Si ce n'était qu'en informtique cela serait supportable ;-)
C'est le pendant malheureux de l'automatisation et du progès d'une
manière générale. Il n'est plus nécessaire de comprendre les basses couches
pour manipuler des machines/services qui auraient demandé des savoirs
difficiles à acquerir à la génération antérieure.
Dans la plupart des cas tout cela permet à un plus grand nombre de
pouvoir intervenir sur ces systèmes sauf dans les cas où l'état du
système est en dehors des cas prévus par le manuel (ce qui ne manque
jamais d'arriver ;-))
C'est là que les "spécialistes" ou les "experts" interviennent.
Ces "esperts" sont simplement des personnes qui ont pris le temps
d'éétudier un peu plus en profondeur le système plutôt que de se
contenter des bêtes instructions à suivres détaillées sur une procédure
trop souvent obsolète et/ou corrigées à la rache au fil des versions par
des personnes n'ayant pas suffisamment d'historique pour comprendre
l'intégralité des implications de leurs modifications.
Quand on en est là, on n'est plus très loin de la catastrophe :)

Par exemple, imaginons un constructeur informatique comme HP:
est-il mieux qu'il fassent eux-mêmes des packages Debian de merde, ou des
packages snap un peu confinés ? La réponse parfaite est: "ils devraient
publier leurs interfaces en open-source et laisser les développeurs
Debian faire de jolis packages". Dans les faits, ils vont se
ruer sur snap (?).
Exemple: j'ai une fois installé un serveur HP, et ils proposaient
des packages Debian pour leur outils de monitoring (leur interface,
à l'époque, était différente des autres constructeurs, différente
de celle supportée par Debian en natif, donc). J'ai regardé le
package et j'ai vu assez vite le risque de rm -rf /$install_dir
avec une variable $install_dir pouvant dans certains cas être
vides ... j'ai essayé de reporter l'erreur, mais je me suis perdu
sur le site web d'HP.

Réfléchir c'est déjà désobéïr !
Outrecuidant et mécréant sysadmin qui ose lire, vérifier et comprendre
ce qu'on lui demande de faire plutôt qu'exécuter une procédure sainte
respectée par tous et qui n'a d'égales en pureté que les tables de la lois :)

Avec des zillions de paquets installés de cette manière il n'y a plus
vraiment moyen de s'assurer de la mise à jour des versions de libs pour
l'ensemble du système et des applications.

Clairement.
Et il y a aussi un impact de gaspillage mémoire.
On a là le térreau idéal pour avoir des systèmes mal/partiellement mis à
jour. C'est surtout ça mon point.

Parfaitement d'accord.

Nous sommes malheureusement minoritaires :-/
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

Eric Masson

13/05/2018 à 11:55

Doug713705 writes:
'Lut,

Pas moins non plus.

Balle au centre, donc.

Mauvais gestionnaire de paquets, changer gestionnaire de paquets.

Ça arrive même avec les outils debian...

Tout ceci est possible grace à la virtualisation sans passer par la
containerisation.

Ok, donc, plusieurs VMs posent moins de problème de màj que quelques
applis sous container ? Intéressant comme concept.
Sachant que les containers sont construits automatiquement à partir d'un
système de paquets, si ce dernier est à jour (pas de raison qu'il le
soit moins que celui du système hôte), les applications empaquetées le
seront tout autant.

Ok pour ça mais qui de la réalité de la chaine de confiance de ces
paquets ?

Voir le paragraphe précédent.

Dans une grande majorité de cas que j'ai pu voir, c'est toujours un
foutoir dès qu'on essaie de tracer l'origine exacte des libs fournies.
Il n'est pas rare d'en trouver d'origines obscures simplement
empaquetées par le dev qui a trouver la solution à son problème en
téléchargeant depuis un site improbable une lib qui résoud ses
problématiques mais qui potentiellement ouvre un peu trop grand les
portes.

Alors qu'un développeur qui travaille pour une distribution connue et
applique des patchs à la con sur un soft aussi sensible qu'OpenSSL, ça
n'existe bien évidemment pas (ah, il me semble que Debian a fait
quelques conneries de ce genre et n'est donc pas l'abri d'en refaire...)

C'est vrai mais la containerisation ajoute une raison supplémentaire
de ne pas (bien) mettre à jour.

Ben non, parce qu'appli containerisée ou pas, elle ne sera pas mise à
jour ou alors avec un retard copieux par rapport aux sources de
référence (faut aller voir dans le vrai monde parfois, là où les
contraintes sont un peu plus exotiques et fortes que sur le serveur de
cuisine du geekounet moyen).

Tout ça n'améliore en rien la securité, dire le contraire est mensonge.
C'était mon point.

Le fait de pouvoir remettre un container dans son état initial
facilement et de pouvoir inspecter les opérations qui sont menées afin
de déterminer quels mécanismes ont été utilisés pour le compromettre, si
c'est le cas, est un outil efficace pour améliorer la sécurité.
Encore une fois, c'est un outil complémentaire qui n'est pas destiné à
se substituer à un gestionnaire de paquets...
--
JL> Ce forum pourrait avantageusement être remplacé par un channel irc
JL> et un jeu de flechettes à l'éfigie de votre neuneu préféré.
Parti comme c'est, vous pouvez commencer à scanner votre photo
-+- JN in <http://www.le-gnu.net/> - Tu flechette tout le monde -+-

Doug713705 <doug.letough@free.fr> writes:

'Lut,

Pas moins non plus.

Balle au centre, donc.

Mauvais gestionnaire de paquets, changer gestionnaire de paquets.

Ça arrive même avec les outils debian...

Tout ceci est possible grace à la virtualisation sans passer par la
containerisation.

Ok, donc, plusieurs VMs posent moins de problème de màj que quelques
applis sous container ? Intéressant comme concept.

Sachant que les containers sont construits automatiquement à partir d'un
système de paquets, si ce dernier est à jour (pas de raison qu'il le
soit moins que celui du système hôte), les applications empaquetées le
seront tout autant.

Ok pour ça mais qui de la réalité de la chaine de confiance de ces
paquets ?

Voir le paragraphe précédent.

Dans une grande majorité de cas que j'ai pu voir, c'est toujours un
foutoir dès qu'on essaie de tracer l'origine exacte des libs fournies.
Il n'est pas rare d'en trouver d'origines obscures simplement
empaquetées par le dev qui a trouver la solution à son problème en
téléchargeant depuis un site improbable une lib qui résoud ses
problématiques mais qui potentiellement ouvre un peu trop grand les
portes.

Alors qu'un développeur qui travaille pour une distribution connue et
applique des patchs à la con sur un soft aussi sensible qu'OpenSSL, ça
n'existe bien évidemment pas (ah, il me semble que Debian a fait
quelques conneries de ce genre et n'est donc pas l'abri d'en refaire...)

C'est vrai mais la containerisation ajoute une raison supplémentaire
de ne pas (bien) mettre à jour.

Ben non, parce qu'appli containerisée ou pas, elle ne sera pas mise à
jour ou alors avec un retard copieux par rapport aux sources de
référence (faut aller voir dans le vrai monde parfois, là où les
contraintes sont un peu plus exotiques et fortes que sur le serveur de
cuisine du geekounet moyen).

Tout ça n'améliore en rien la securité, dire le contraire est mensonge.
C'était mon point.

Le fait de pouvoir remettre un container dans son état initial
facilement et de pouvoir inspecter les opérations qui sont menées afin
de déterminer quels mécanismes ont été utilisés pour le compromettre, si
c'est le cas, est un outil efficace pour améliorer la sécurité.

Encore une fois, c'est un outil complémentaire qui n'est pas destiné à
se substituer à un gestionnaire de paquets...

--
JL> Ce forum pourrait avantageusement être remplacé par un channel irc
JL> et un jeu de flechettes à l'éfigie de votre neuneu préféré.
Parti comme c'est, vous pouvez commencer à scanner votre photo
-+- JN in <http://www.le-gnu.net/> - Tu flechette tout le monde -+-

Vous avez filtré cet utilisateur ! Consultez son message

Doug713705 writes:
'Lut,

Pas moins non plus.

Balle au centre, donc.

Mauvais gestionnaire de paquets, changer gestionnaire de paquets.

Ça arrive même avec les outils debian...

Tout ceci est possible grace à la virtualisation sans passer par la
containerisation.

Ok, donc, plusieurs VMs posent moins de problème de màj que quelques
applis sous container ? Intéressant comme concept.
Sachant que les containers sont construits automatiquement à partir d'un
système de paquets, si ce dernier est à jour (pas de raison qu'il le
soit moins que celui du système hôte), les applications empaquetées le
seront tout autant.

Ok pour ça mais qui de la réalité de la chaine de confiance de ces
paquets ?

Voir le paragraphe précédent.

Dans une grande majorité de cas que j'ai pu voir, c'est toujours un
foutoir dès qu'on essaie de tracer l'origine exacte des libs fournies.
Il n'est pas rare d'en trouver d'origines obscures simplement
empaquetées par le dev qui a trouver la solution à son problème en
téléchargeant depuis un site improbable une lib qui résoud ses
problématiques mais qui potentiellement ouvre un peu trop grand les
portes.

Alors qu'un développeur qui travaille pour une distribution connue et
applique des patchs à la con sur un soft aussi sensible qu'OpenSSL, ça
n'existe bien évidemment pas (ah, il me semble que Debian a fait
quelques conneries de ce genre et n'est donc pas l'abri d'en refaire...)

C'est vrai mais la containerisation ajoute une raison supplémentaire
de ne pas (bien) mettre à jour.

Ben non, parce qu'appli containerisée ou pas, elle ne sera pas mise à
jour ou alors avec un retard copieux par rapport aux sources de
référence (faut aller voir dans le vrai monde parfois, là où les
contraintes sont un peu plus exotiques et fortes que sur le serveur de
cuisine du geekounet moyen).

Tout ça n'améliore en rien la securité, dire le contraire est mensonge.
C'était mon point.

Le fait de pouvoir remettre un container dans son état initial
facilement et de pouvoir inspecter les opérations qui sont menées afin
de déterminer quels mécanismes ont été utilisés pour le compromettre, si
c'est le cas, est un outil efficace pour améliorer la sécurité.
Encore une fois, c'est un outil complémentaire qui n'est pas destiné à
se substituer à un gestionnaire de paquets...
--
JL> Ce forum pourrait avantageusement être remplacé par un channel irc
JL> et un jeu de flechettes à l'éfigie de votre neuneu préféré.
Parti comme c'est, vous pouvez commencer à scanner votre photo
-+- JN in <http://www.le-gnu.net/> - Tu flechette tout le monde -+-

yamo'

14/05/2018 à 10:25

Salut,
Dominique a écrit le 10/05/2018 à 07:05 :

Merci pour vos lumières et bonne journée à tous,

Merci! Grâce à cette question, je viens d'installer snap sur debian 9 et
par exemple ça permet d'avoir gimp 2.10 en plus de gimp 2.8 sans grosses
manipulations.
Très intéressant pour tester une application.
--
Stéphane

Jo Engo

14/05/2018 à 15:24

Le Mon, 14 May 2018 10:25:04 +0200, yamo' a écrit :

Très intéressant pour tester une application.

Est-ce pratique ?
--
P : Mais... qu'est-ce que tu fous ?!
M : Je soigenmes hémorrhoïdes par les plantes...

yamo'

14/05/2018 à 20:35

Jo Engo a écrit le 14/05/2018 à 15:24 :

Le Mon, 14 May 2018 10:25:04 +0200, yamo' a écrit :
Très intéressant pour tester une application.

Est-ce pratique ?

Oui, par contre il faut le compte root pour installer une application.
Je le teste depuis ce matin et ça fonctionne bien.
Pour lancer gimp 2.10 (je n'ai pas vu de lanceur dans le menu lxde) :
$ snap run gimp
Par contre, je n'accède pas à tous les points de montage.
--
Stéphane

Ubuntu 18.04 et partitions

8 réponses

Veuillez sélectionner un problème