Re: Certificat de confiance sur équipements industriels

2019-01-20 Par sujet Jack.R 
Le Mon, 21 Jan 2019 07:51:46 +0100,
Pierre Malard  a écrit :

> Bonjour,
> 
> Le comportement de ces navigateur est logique avec la philosophie
> d’une connexion sécurisée par une autorité. Celle-ci doit être
> reconnue pour assurer la confidentialité des échanges. La plupart
> des utilisateurs/constructeurs laissent le certificat « snake oil »
> de base mais, par évidence, ce système ne peut être considéré
> comme sûr.
> 
> Une réponse certainement bête mais … avez-vous demandé au constructeur
> de ces équipement s’il n’était pas possesseur d’un vrai certificat ?
> Visiblement, c’est lui qui impose l’utilisation d’un traitement par
> certificat, qu’il propose donc une solution certifiée.
> 
> Une autre solution puisque vous dites que la machine n’est pas sur
> un réseau connecté : passer sur une connexion sans cryptage. Ce ne
> sera pas moins sûr que le certificat de base et si cet équipement
> est réellement isolé, cela ne présente pas véritablement de danger
> à moins d’être directement et physiquement connecté dessus, donc
> à côté.
> 
> Autre solution si vous avez accès à la configuration de la machine,
> est-ce que vous ne pouvez pas y coller un certificat d’autorité et
> le faire reconnaître une fois pour toute par le navigateur (Chrome,
> Firefox) pour qu’il cesse de vous em… ?
> 
> Cordialement

Bonjour,

La réponse actuelle du/des constructeur(s) est le certificat auto-signé
car il ne leur semble pas possible d'avoir un vrai certificat sur des
équipements dont ils ne maitrisent ni le nom de machine ni l'IP,
d'où ma recherche pour essayer de voir s'il n'y a pas malgré tout
une solution.

J'ai un accès partiel au système, certaines applications ne
permettent pas de passer hors HTTPS/SSL. Je comprend bien que les
constructeurs ne souhaitent pas, par exemple, que les identifiants
permettant d'interagir avec l’équipement passent en clair sur un
réseau quel qu'il soit. 

Y coller un certificat d'autorité est bien mon idée sauf que je me
heurte (connaissance insuffisante de ma part) à:
comment je fais pour créer un certificat d'autorité pour un équipement
où nom de domaine, nom de machine, IP peuvent varier ? 
Pour moi, de ce que j'ai compris, je dois en créer un à chaque fois que
l'équipement change de nom de domaine, de nom de machine, d'ip.
J'avais pensé à la création à la volée via lets encrypt (ou autre) mais
dans ce cas j'ai besoin d'une connexion internet et d'un renouvellement
régulier sur chaque équipements.

Autre idée, avoir un nom de machine unique et non modifiable par
l'opérateur (je force un alias sur 127.0.0.1 par exemple) sur lequel je
pourrais créer ce certificat d'autorité qui serait reconnu comme de
confiance par les navigateurs mais je n'arrive pas à voir comment créer
cela pour plusieurs centaines d'équipements (gestion, coût), d'où mon
message.
Un certificat *.mondomaine me semblant absurde et contraire à l'idée du
chiffrement.

Cordialement
-- 
Jack.R

Re: Certificat de confiance sur équipements industriels

2019-01-20 Par sujet Pierre Malard 
Bonjour,

Le comportement de ces navigateur est logique avec la philosophie
d’une connexion sécurisée par une autorité. Celle-ci doit être
reconnue pour assurer la confidentialité des échanges. La plupart
des utilisateurs/constructeurs laissent le certificat « snake oil »
de base mais, par évidence, ce système ne peut être considéré
comme sûr.

Une réponse certainement bête mais … avez-vous demandé au constructeur
de ces équipement s’il n’était pas possesseur d’un vrai certificat ?
Visiblement, c’est lui qui impose l’utilisation d’un traitement par
certificat, qu’il propose donc une solution certifiée.

Une autre solution puisque vous dites que la machine n’est pas sur
un réseau connecté : passer sur une connexion sans cryptage. Ce ne
sera pas moins sûr que le certificat de base et si cet équipement
est réellement isolé, cela ne présente pas véritablement de danger
à moins d’être directement et physiquement connecté dessus, donc
à côté.

Autre solution si vous avez accès à la configuration de la machine,
est-ce que vous ne pouvez pas y coller un certificat d’autorité et
le faire reconnaître une fois pour toute par le navigateur (Chrome,
Firefox) pour qu’il cesse de vous em… ?

Cordialement

> Le 20 janv. 2019 à 20:16, Jack.R  a écrit :
> 
> Bonjour,
> 
> J'utilise des contrôleurs d'équipements industriels qui ont une base
> Debian Stretch customisée par le fabriquant de la carte CPU.
> Ces équipements embarquent un certain nombre de services (serveur
> web, serveur ssh, serveur FTP, ...)
> Certaines connexions sont chiffrées en SSL avec un certificat
> auto-signé.
> Les versions actuelles de navigateurs (firefox, chrome, ...)
> déclenchent systématiquement un avertissement, il faut mettre une
> exception et, si c'est faisable, la rendre permanente.
> 
> Imaginez que vous êtes l'opérateur qui tous les matins démarre sa
> machine avec une belle interface web et qui doit créer/accepter
> l'exception pour un certificat auto-signé dont il n'a pas la moindre
> idée de ce que c'est.
> 
> Je cherche un moyen de mettre un certificat (ou une chaîne) valide et
> reconnu par les navigateurs comme de confiance.
> 
> Une solution style let's encrypt (certbot) ne me semble pas valide car:
> - les équipements n'ont pas de connexion avec internet (impossible de
>  renouveler le certificat),
> - l'ip et le nom de machine sont définis par l'utilisateur final et en
>  fonction du secteur d'installation il peut même y avoir du DHCP,
> - les équipements ne sont pas forcément reliés au réseau usine (pas de
>  possibilité d'utiliser un serveur interne avec une chaîne de
>  certificats),
> - dans la même machine, je peux avoir plusieurs de ces équipements
>  (impossible d'avoir un nom de machine/domaine -fqdn- identique)
> 
> mkcert comme utilisé ici:
> https://lehollandaisvolant.net/?d=2019/01/07/22/57/47-localhost-et-https
> ne cadre pas car le navigateur n'est pas nécessairement celui embarqué
> par l'équipement, on peut effectuer un accès distant pour un écran
> déporté affichant par exemple le status de l'équipement.
> 
> Si certains ont des pistes de recherches, je suis preneur car mes
> recherches avec "trusted certificat industrial equipment" et un
> apt-cache search certificate ne me retourne pas de résultat qui me
> semblent intéressants.
> 
> Rassurez-moi, les éditeurs de navigateur ont bien pensé à ce cas de
> figure lorsqu'ils on décidé "d'imposer" HTTPS et TLS?
> Je me pose la question lorsque je lis la portion "For native apps
> talking to web apps" de:
> https://letsencrypt.org/docs/certificates-for-localhost/
> 
> --
> Jack.R
> 

--
Pierre Malard

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_) πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: récupérer son N° de tel free pour le mettre sur l'ordi

2019-01-20 Par sujet Haricophile 
Le Sun, 20 Jan 2019 21:45:04 +0100 (CET),
Bernard Schoenacker  a écrit :

> bonjour,
> 
> cf sujet et comment faire ?
> 
> merci de votre aimable attention
> 
> 
> slt
> bernard
> 

Je ne comprends pas la question.

Re: [HS] GAFAM est devenu GAFA

2019-01-20 Par sujet Ph. Gras 
Salut la liste,

> Pan dans le mille,
> Tu as gagné le futur Windows 12 (dès sorti) :-)
> 
> + de nos écoles avec gros chèque pour l'EN à l'appui.
> Microsoft a bien compris l'importance de s'installer dans les écoles,
> l'âge ou tout s'inscrit dans les cerveaux : "Informatique = Microsoft".

Ça peut-être serait intéressant de porter ce fait à la connaissance du plus 
large public, à contrario du
logiciel libre qui offrirait la possibilité à l'administration d'opérer de 
substantielles économies, en plus
de mettre en œuvre des applications un peu mieux réfléchies que celles dont nos 
augustes ministres
(… et leurs assujettis) bénéficient aujourd'hui.

> 
> Bref, elle ne paiera donc pas la taxe GAFA(M).
> 

Si quelqu'un a des infos là-dessus, je suis preneur d'autant plus que j'ai lu 
le lendemain de l'annonce
que Gogol était déjà en train de réfléchir à des mesures pour s'y soustraire…

Bonne nuit,

Ph. Gras

Re: [HS] GAFAM est devenu GAFA

2019-01-20 Par sujet ajh-valmer 
On Sunday 20 January 2019 22:40:26 JC.EtiembleG wrote:
> Le 20/01/2019 à 22:34, ajh-valmer a écrit :
> > Je constate que GAFAM est devenu GAFA.
> > La bande des 5 est passé à 4.
> > Le M de Microsoft a disparu des écrans radar.
> > Pourquoi ? :

> Microsoft est fournisseur de la défense nationale française alors :) :

Pan dans le mille,
Tu as gagné le futur Windows 12 (dès sorti) :-)

+ de nos écoles avec gros chèque pour l'EN à l'appui.
Microsoft a bien compris l'importance de s'installer dans les écoles,
l'âge ou tout s'inscrit dans les cerveaux : "Informatique = Microsoft".

Bref, elle ne paiera donc pas la taxe GAFA(M).

Re: problème avec ftp.fr.debian.org

2019-01-20 Par sujet Étienne Mollier 
Pierre Frenkiel, au 2019-01-20 :
>En fait, comme je l'ai dit, ce qui me gêne, c'est que
>ftp.fr soit différent de ftp.us.
>Ça me parait en contradiction avec la notion de miroir.

Ce n'est qu'une conjecture, mais peut-être que votre dernière
update a eu lieu entre deux synchronisations des miroirs fr et
us.  Ces derniers semblent être d'accord à l'instant t,
vis-à-vis des paquets linux-compiler-gcc-6 à mettre à
disposition :

http://ftp.us.debian.org/debian/pool/main/l/linux/
http://ftp.fr.debian.org/debian/pool/main/l/linux/

Comme l'indiquait Pascal, c'est l'index, ici décrit par
l'arborescence dists/, qui fait foi quant à la disponibilité des
paquets sur un dépôt.  Le pool/ contient en vrac les paquets de
l'ensemble des distributions mises à disposition par le dépôt
(pêle-mêle : « stretch », « unstable », « stretch-backports »,
« testing » ...)

Le mirroring en question est, je crois, effectué par des appels
réguliers à une commande « ftpsync », mais n'a pas forcément le
caractère instantané d'un Raid 1.  Si quelqu'un maintenant un
miroir officiel dans l'assemblée peut confirmer ?...

>2 questions:
>1/ qu'appelles-tu  "base de connaissance d'aptitude"?

J'appelais « base de connaissance d'aptitude », les informations
sur les paquets disponibles dans les dépôts, construite en local
sur votre machine au moment de l'exécution de la commande
« aptitude update ».  Ces métadonnées sont réutilisée par les
commandes comme « aptitude search » ou « aptitude show » sans
avoir à se reconnecter au dépôt distant.  Elles sont également
utilisées lors des commandes « aptitude install » ou « aptitude
upgrade » pour connaître l'URL de récupération des paquets
requis.

Quand un paquet disparaît d'un dépôt, mais est demandé par un
par un client « aptitude » dont la base locale de connaissance
de paquets n'est plus à jour, cette erreur 404 peut se produire.

J'utilise apt, mais je suppose que le principe est identique
pour aptitude, basé sur les même outils.  Dans mon cas, cette
base de connaissance est constituée de l'ensemble des fichiers
stockés dans l'arborescence /var/lib/apt/lists/.

>2/ qu'appelles-tu  "miroir auquel il est raccordé"?

J'appelais « miroir auquel il est raccordé », le dépôt spécifié
dans /etc/apt/sources.list que apt va utiliser pour récupérer
les paquets à installer.  Désolé pour le manque de clarté...

Amicalement,
-- 
Étienne Mollier

Re: [HS] GAFAM est devenu GAFA

2019-01-20 Par sujet JC.EtiembleG 

Le 20/01/2019 à 22:34, ajh-valmer a écrit :

Je constate que GAFAM est devenu GAFA.

La bande des 5 est passé à 4.

Le M de Microsoft a disparu des écrans radar.


Microsoft est fournisseur de la défense nationale française alors :)


--
J-C Etiemble

[HS] GAFAM est devenu GAFA

2019-01-20 Par sujet ajh-valmer 
Je constate que GAFAM est devenu GAFA.

La bande des 5 est passé à 4.

Le M de Microsoft a disparu des écrans radar.

Pourquoi ?

Re: Failed to start load kernel modules

2019-01-20 Par sujet ajh-valmer 
On Sunday 20 January 2019 10:25:49 Pascal Hambourg wrote:
> Le 19/01/2019 à 22:21, ajh-valmer a écrit :
> > On Saturday 19 January 2019 18:52:28 Pascal Hambourg wrote:
> >> Le 19/01/2019 à 16:25, ajh-valmer a écrit :
> >>> J'ai ce message au boot de Stretch :
> >>> "Failed to start load kernel modules"
> >>> à la suite d'un changement d'ordinateur.
> >>> Mais lequel ou lesquels module(s) ?

> "coretemp" n'est pas un processus, c'est un module du noyau. 
> Sa  description indique :
> # modinfo -d coretemp
> Intel Core temperature monitor
> 
> Il ne convient donc pas si le processeur de la nouvelle machine n'est 
> pas un Intel Core. 

Pas la peine d'insister, mon autre ordinateur a un processeur
AMD. 
J'ai retiré "coretemp" de "/etc/modules" et je n'ai plus ce message.

Merci.

Très bonne fin de soirée,

A. Valmer

récupérer son N° de tel free pour le mettre sur l'ordi

2019-01-20 Par sujet Bernard Schoenacker 
bonjour,

cf sujet et comment faire ?

merci de votre aimable attention


slt
bernard

Certificat de confiance sur équipements industriels

2019-01-20 Par sujet Jack.R 
Bonjour,

J'utilise des contrôleurs d'équipements industriels qui ont une base
Debian Stretch customisée par le fabriquant de la carte CPU.
Ces équipements embarquent un certain nombre de services (serveur
web, serveur ssh, serveur FTP, ...)
Certaines connexions sont chiffrées en SSL avec un certificat
auto-signé. 
Les versions actuelles de navigateurs (firefox, chrome, ...)
déclenchent systématiquement un avertissement, il faut mettre une
exception et, si c'est faisable, la rendre permanente.

Imaginez que vous êtes l'opérateur qui tous les matins démarre sa
machine avec une belle interface web et qui doit créer/accepter
l'exception pour un certificat auto-signé dont il n'a pas la moindre
idée de ce que c'est. 

Je cherche un moyen de mettre un certificat (ou une chaîne) valide et
reconnu par les navigateurs comme de confiance. 

Une solution style let's encrypt (certbot) ne me semble pas valide car:
- les équipements n'ont pas de connexion avec internet (impossible de
  renouveler le certificat),
- l'ip et le nom de machine sont définis par l'utilisateur final et en
  fonction du secteur d'installation il peut même y avoir du DHCP,
- les équipements ne sont pas forcément reliés au réseau usine (pas de
  possibilité d'utiliser un serveur interne avec une chaîne de
  certificats),
- dans la même machine, je peux avoir plusieurs de ces équipements
  (impossible d'avoir un nom de machine/domaine -fqdn- identique)

mkcert comme utilisé ici:
https://lehollandaisvolant.net/?d=2019/01/07/22/57/47-localhost-et-https
ne cadre pas car le navigateur n'est pas nécessairement celui embarqué
par l'équipement, on peut effectuer un accès distant pour un écran
déporté affichant par exemple le status de l'équipement.

Si certains ont des pistes de recherches, je suis preneur car mes
recherches avec "trusted certificat industrial equipment" et un
apt-cache search certificate ne me retourne pas de résultat qui me
semblent intéressants.

Rassurez-moi, les éditeurs de navigateur ont bien pensé à ce cas de
figure lorsqu'ils on décidé "d'imposer" HTTPS et TLS?
Je me pose la question lorsque je lis la portion "For native apps
talking to web apps" de:
https://letsencrypt.org/docs/certificates-for-localhost/

-- 
Jack.R

Re: problème avec ftp.fr.debian.org

2019-01-20 Par sujet Pierre Frenkiel 

On Sun, 20 Jan 2019, etienne.moll...@mailoo.org wrote:


Le 2019-01-20 11:47, Pierre Frenkiel a écrit :

On Sun, 20 Jan 2019, Bernard Schoenacker wrote:




- Mail original -

De: "Pierre Frenkiel" 
À: debian-user-french@lists.debian.org
Envoyé: Dimanche 20 Janvier 2019 11:08:18
Objet: problème avec ftp.fr.debian.org

bonjour,
en faisant un aptitude upgrade:
avec:
deb http://ftp.fr.debian.org/debian stretch main contrib non-free
Failed to fetch
http://ftp.fr.debian.org/debian/pool/main/l/linux/linux-compiler-gcc-6-x86_4.9.135-1_i386.deb:
404  Not Found [IP: 212.27.32.66 80]

avec:
deb http://ftp.us.debian.org/debian stretch main contrib non-free
OK

est-ce bien normal?

Cordialement,



bonjour,


il n'y a pas de paquet de dispo avec cette version sur le
site français ...

inexistant :
gcc-6-x86_4.9.135-1_i386.deb


  s'il n'existe pas, pourquoi "aptitude upgrade" essaie-t-il de le charger?


Bonjour,

On dirait un écart entre la base de connaissance d'aptitude
et l'état du miroir auquel il est raccordé.  Qu'est ce que ça
donne en lançant successivement :

   # aptitude update
   # aptitude safe-upgrade

Amicalement,
--
Étienne Mollier 


   merci Etienne pour cette suggestion, mais c'est exactement ce que j'avais 
fait
   De toutes façons, maintenant la version 4.9.144-1 est installée, et il 
faudrait que je
   la supprime  et repasse à ftp.fr pour refaire l'essai.
   En fait, comme je l'ai dit, ce qui me gêne, c'est que ftp.fr soit différent 
de ftp.us.
   Ça me parait en contradiction avec la notion de miroir.
   2 questions:
   1/ qu'appelles-tu  "base de connaissance d'aptitude"?
   2/ qu'appelles-tu  "miroir auquel il est raccordé"?

Cordialement,
--
Pierre Frenkiel

Re: problème avec ftp.fr.debian.org

2019-01-20 Par sujet Pascal Hambourg 

Le 20/01/2019 à 11:47, Pierre Frenkiel a écrit :

On Sun, 20 Jan 2019, Bernard Schoenacker wrote:



De: "Pierre Frenkiel" 
en faisant un aptitude upgrade:
avec:
    deb http://ftp.fr.debian.org/debian stretch main contrib non-free
Failed to fetch
http://ftp.fr.debian.org/debian/pool/main/l/linux/linux-compiler-gcc-6-x86_4.9.135-1_i386.deb: 


404  Not Found [IP: 212.27.32.66 80]

avec:
    deb http://ftp.us.debian.org/debian stretch main contrib non-free
    OK

est-ce bien normal?

(...)

il n'y a pas de paquet de dispo avec cette version sur le
site français ...

inexistant :
gcc-6-x86_4.9.135-1_i386.deb


   s'il n'existe pas, pourquoi "aptitude upgrade" essaie-t-il de le 
charger?


Parce que c'est une version obsolète et que la base de paquets 
d'aptitude n'est pas à jour. As-tu exécuté aptitude update avant ?



paquet existant sur le miroir français :
linux-compiler-gcc-6-x86_4.9.144-1_i386.deb


Version présente dans stretch-proposed-updates (destinée à être intégrée 
dans la prochaine publication de stretch).



linux-compiler-gcc-6-x86_4.19.12-1~bpo9+1_i386.deb


Version présente dans stretch-backports.
Comme on peut le voir sur 
 la 
version actuellement présente dans stretch est 4.9.130-2, disponible sur 
le miroir fr.



   avec ftp.us.., j'ai
  ii  linux-compiler-gcc-6-x86 4.9.144-1    i386


Version de stretch-proposed-updates


  ii  linux-compiler-gcc-7-x86 4.18.10-2    i386


Version obsolète de buster.

   si les contenus des sites fr et us sont différents, la notion de 
miroir ne me semble pas vraiment respectée...


Apparemment le miroir us ne nettoie pas les .deb obsolète immédiatement.
Ce n'est pas les .deb présents qu'il faut regarder, mais l'index des 
paquets.

Re: problème avec ftp.fr.debian.org

2019-01-20 Par sujet etienne . mollier 

Le 2019-01-20 11:47, Pierre Frenkiel a écrit :

On Sun, 20 Jan 2019, Bernard Schoenacker wrote:




- Mail original -

De: "Pierre Frenkiel" 
À: debian-user-french@lists.debian.org
Envoyé: Dimanche 20 Janvier 2019 11:08:18
Objet: problème avec ftp.fr.debian.org

bonjour,
en faisant un aptitude upgrade:
avec:
deb http://ftp.fr.debian.org/debian stretch main contrib non-free
Failed to fetch
http://ftp.fr.debian.org/debian/pool/main/l/linux/linux-compiler-gcc-6-x86_4.9.135-1_i386.deb:
404  Not Found [IP: 212.27.32.66 80]

avec:
deb http://ftp.us.debian.org/debian stretch main contrib non-free
OK

est-ce bien normal?

Cordialement,



bonjour,


il n'y a pas de paquet de dispo avec cette version sur le
site français ...

inexistant :
gcc-6-x86_4.9.135-1_i386.deb


  s'il n'existe pas, pourquoi "aptitude upgrade" essaie-t-il de le 
charger?


Bonjour,

On dirait un écart entre la base de connaissance d'aptitude
et l'état du miroir auquel il est raccordé.  Qu'est ce que ça
donne en lançant successivement :

# aptitude update
# aptitude safe-upgrade

Amicalement,
--
Étienne Mollier

Re: problème avec ftp.fr.debian.org

2019-01-20 Par sujet Pierre Frenkiel 

On Sun, 20 Jan 2019, Bernard Schoenacker wrote:




- Mail original -

De: "Pierre Frenkiel" 
À: debian-user-french@lists.debian.org
Envoyé: Dimanche 20 Janvier 2019 11:08:18
Objet: problème avec ftp.fr.debian.org

bonjour,
en faisant un aptitude upgrade:
avec:
deb http://ftp.fr.debian.org/debian stretch main contrib non-free
Failed to fetch
http://ftp.fr.debian.org/debian/pool/main/l/linux/linux-compiler-gcc-6-x86_4.9.135-1_i386.deb:
404  Not Found [IP: 212.27.32.66 80]

avec:
deb http://ftp.us.debian.org/debian stretch main contrib non-free
OK

est-ce bien normal?

Cordialement,



bonjour,


il n'y a pas de paquet de dispo avec cette version sur le
site français ...

inexistant :
gcc-6-x86_4.9.135-1_i386.deb


  s'il n'existe pas, pourquoi "aptitude upgrade" essaie-t-il de le charger?



paquet existant sur le miroir français :
linux-compiler-gcc-6-x86_4.9.144-1_i386.deb
linux-compiler-gcc-6-x86_4.19.12-1~bpo9+1_i386.deb


  avec ftp.us.., j'ai
 ii  linux-compiler-gcc-6-x86 4.9.144-1i386
 ii  linux-compiler-gcc-7-x86 4.18.10-2i386

  si les contenus des sites fr et us sont différents, la notion de miroir ne me 
semble
  pas vraiment respectée...

Cordialement,
--
Pierre Frenkiel

Re: problème avec ftp.fr.debian.org

2019-01-20 Par sujet Bernard Schoenacker 



- Mail original -
> De: "Pierre Frenkiel" 
> À: debian-user-french@lists.debian.org
> Envoyé: Dimanche 20 Janvier 2019 11:08:18
> Objet: problème avec ftp.fr.debian.org
> 
> bonjour,
> en faisant un aptitude upgrade:
> avec:
> deb http://ftp.fr.debian.org/debian stretch main contrib non-free
> Failed to fetch
> http://ftp.fr.debian.org/debian/pool/main/l/linux/linux-compiler-gcc-6-x86_4.9.135-1_i386.deb:
> 404  Not Found [IP: 212.27.32.66 80]
> 
> avec:
> deb http://ftp.us.debian.org/debian stretch main contrib non-free
> OK
> 
> est-ce bien normal?
> 
> Cordialement,


bonjour,


il n'y a pas de paquet de dispo avec cette version sur le 
site français ...

inexistant :
gcc-6-x86_4.9.135-1_i386.deb


paquet existant sur le miroir français :
linux-compiler-gcc-6-x86_4.9.144-1_i386.deb
linux-compiler-gcc-6-x86_4.19.12-1~bpo9+1_i386.deb

merci
slt
bernard

problème avec ftp.fr.debian.org

2019-01-20 Par sujet Pierre Frenkiel 

bonjour,
en faisant un aptitude upgrade:
avec:
   deb http://ftp.fr.debian.org/debian stretch main contrib non-free
Failed to fetch 
http://ftp.fr.debian.org/debian/pool/main/l/linux/linux-compiler-gcc-6-x86_4.9.135-1_i386.deb:
 404  Not Found [IP: 212.27.32.66 80]

avec:
   deb http://ftp.us.debian.org/debian stretch main contrib non-free
   OK

est-ce bien normal?

Cordialement,
--
Pierre Frenkiel

Re: Failed to start load kernel modules

2019-01-20 Par sujet Pascal Hambourg 

Le 19/01/2019 à 22:21, ajh-valmer a écrit :

On Saturday 19 January 2019 18:52:28 Pascal Hambourg wrote:

Le 19/01/2019 à 16:25, ajh-valmer a écrit :

J'ai ce message au boot de Stretch :
"Failed to start load kernel modules"
à la suite d'un changement d'ordinateur.
Mais lequel ou lesquels module(s) ?



Probablement un de ceux listés dans /etc/modules ou
/etc/modules-load.d/*. Je parierais sur un pilote de capteur de
température/tension/vitesse de ventilateur ajouté par lm-sensors pour
l'ordinateur précédent.
Peut-être plus de détails avec

service kmod status

(...)

J'ai trouvé cette info, taper :
# systemctl status systemd-modules-load.service


Cette commande est équivalente à celle que j'avais indiquée ci-dessus 
(qui fonctionne aussi sur les systèmes n'ayant pas systemd).



Je reçois :
Process:212

# journalctl -b _PID=212

Il s'agit du processus "coretemp".


"coretemp" n'est pas un processus, c'est un module du noyau. Sa 
description indique :


# modinfo -d coretemp
Intel Core temperature monitor

Il ne convient donc pas si le processeur de la nouvelle machine n'est 
pas un Intel Core. Certains modules se chargent sans erreur même si 
aucun périphérique correspondant n'est présent, d'autres non. Celui-ci 
fait visiblement partie de la seconde catégorie.


Le PID 212 mentionné par systemctl status est celui du processus 
/lib/systemd/systemd-modules-load exécuté par le service
systemd-modules-load.service, ayant pour fonction de charger 
statiquement les modules listés dans divers fichiers comme 
/etc/modules-load.d/modules.conf.



Core Temp est un petit utilitaire très pratique qui affiche en
temps réel la température des cores de votre processeur.
Donc possible qu'il soit lié à un capteur de lm-sensors... ?


Je ne connais pas cet utilitaire "Core Temp", mais ce n'est pas la même 
chose que le module du noyau "coretemp" qui provoquait l'erreur.


Si lm-sensors est installé, tu peux exécuter sensors-detect pour 
rechercher les capteurs présents et ajouter les modules correspondants.