À l'époque où j'étais encore entièrement chez Bill, j'entendais parler
d'uptimes phénoménaux pour des machines Linux -- plusieurs mois, voire
plus d'un an, sans rebooter.
Aujourd'hui, sur un joli serveur, j'ai une distribution dite "stable",
une Debian Etch. Et il ne se passe pas un mois sans qu'une mise à
jour[*] du noyau[**] ne m'oblige à rebooter.
Y a-t-il eu, ces derniers mois, une recrudescence d'alertes de
sécurité dans le noyau Linux ?
Ou bien, les records d'uptime appartiennent-ils à une époque
maintenant révolue ?
Ou encore, est-ce que je m'y prends comme un pied ?
Note : j'ai vérifié mon sources.list, il n'y a là-dedans que du
"etch", pas de trace de "lenny" ni "sid".
Y a-t-il eu, ces derniers mois, une recrudescence d'alertes de sécurité dans le noyau Linux ?
Pas que je sache.
Ou bien, les records d'uptime appartiennent-ils à une époque maintenant révolue ?
Moi, sur des machines à la maison, je ne reboote guère qu'en cas de coupure de courant, où quand je veux toucher au matos. Je compile un noyau à la main au lieu d'utiliser des packages, si bien que rien ne me force à upgrader en permanence (et je limite très fortement mon usage d'udev (je le fais faire sa soupe dans /udev, dont je n'utilise guère que le /udev/bus/usb), donc ma machine n'explose pas à chaque fois qu'une upgrade amène une nouvelle version d'udev qui a besoin du noyau ++n). J'upgrade mon noyau deux ou trois fois par an, et j'atteins souvent des uptimes de plusieurs mois.
Fabien LE LEZ :
Y a-t-il eu, ces derniers mois, une recrudescence d'alertes de
sécurité dans le noyau Linux ?
Pas que je sache.
Ou bien, les records d'uptime appartiennent-ils à une époque
maintenant révolue ?
Moi, sur des machines à la maison, je ne reboote guère qu'en cas de coupure
de courant, où quand je veux toucher au matos. Je compile un noyau à la main
au lieu d'utiliser des packages, si bien que rien ne me force à upgrader en
permanence (et je limite très fortement mon usage d'udev (je le fais faire
sa soupe dans /udev, dont je n'utilise guère que le /udev/bus/usb), donc ma
machine n'explose pas à chaque fois qu'une upgrade amène une nouvelle
version d'udev qui a besoin du noyau ++n). J'upgrade mon noyau deux ou trois
fois par an, et j'atteins souvent des uptimes de plusieurs mois.
Y a-t-il eu, ces derniers mois, une recrudescence d'alertes de sécurité dans le noyau Linux ?
Pas que je sache.
Ou bien, les records d'uptime appartiennent-ils à une époque maintenant révolue ?
Moi, sur des machines à la maison, je ne reboote guère qu'en cas de coupure de courant, où quand je veux toucher au matos. Je compile un noyau à la main au lieu d'utiliser des packages, si bien que rien ne me force à upgrader en permanence (et je limite très fortement mon usage d'udev (je le fais faire sa soupe dans /udev, dont je n'utilise guère que le /udev/bus/usb), donc ma machine n'explose pas à chaque fois qu'une upgrade amène une nouvelle version d'udev qui a besoin du noyau ++n). J'upgrade mon noyau deux ou trois fois par an, et j'atteins souvent des uptimes de plusieurs mois.
Pierre-Hugues HUSSON
Fabien LE LEZ wrote:
Y a-t-il eu, ces derniers mois, une recrudescence d'alertes de sécurité dans le noyau Linux ? Ou bien, les records d'uptime appartiennent-ils à une époque maintenant révolue ? Ou encore, est-ce que je m'y prends comme un pied ?
Bon alors y a plusieurs choses: Quand t'as une mise à jour du noyau, t'es pas obligé de rebooter, faut voir si la mise à jour te concerne. Par exemple une faille de sécurité dans la gestion du port parallèle qui ferait un accès facile par là (oui je dis n'impore quoi), a très peu de chances de te concerne donc pas besoin de faire la mise à jour, comme c'est automatique tu peux la laisser mais pas besoin de rebooter. (Je crois pas que y ait eu de faille de sécurité critique qioferait faire rebooter tous les serveurs cette année). Ensuite les mises à jours de sécurité ne sont nécessaires que s'il y a des problèmes de sécurité. Pour un serveur de base de données accessible uniquement des serveurs web, y a pas besoin de corriger les failles.
Fabien LE LEZ wrote:
Y a-t-il eu, ces derniers mois, une recrudescence d'alertes de
sécurité dans le noyau Linux ?
Ou bien, les records d'uptime appartiennent-ils à une époque
maintenant révolue ?
Ou encore, est-ce que je m'y prends comme un pied ?
Bon alors y a plusieurs choses:
Quand t'as une mise à jour du noyau, t'es pas obligé de rebooter, faut voir
si la mise à jour te concerne. Par exemple une faille de sécurité dans la
gestion du port parallèle qui ferait un accès facile par là (oui je dis
n'impore quoi), a très peu de chances de te concerne donc pas besoin de
faire la mise à jour, comme c'est automatique tu peux la laisser mais pas
besoin de rebooter. (Je crois pas que y ait eu de faille de sécurité
critique qioferait faire rebooter tous les serveurs cette année).
Ensuite les mises à jours de sécurité ne sont nécessaires que s'il y a des
problèmes de sécurité. Pour un serveur de base de données accessible
uniquement des serveurs web, y a pas besoin de corriger les failles.
Y a-t-il eu, ces derniers mois, une recrudescence d'alertes de sécurité dans le noyau Linux ? Ou bien, les records d'uptime appartiennent-ils à une époque maintenant révolue ? Ou encore, est-ce que je m'y prends comme un pied ?
Bon alors y a plusieurs choses: Quand t'as une mise à jour du noyau, t'es pas obligé de rebooter, faut voir si la mise à jour te concerne. Par exemple une faille de sécurité dans la gestion du port parallèle qui ferait un accès facile par là (oui je dis n'impore quoi), a très peu de chances de te concerne donc pas besoin de faire la mise à jour, comme c'est automatique tu peux la laisser mais pas besoin de rebooter. (Je crois pas que y ait eu de faille de sécurité critique qioferait faire rebooter tous les serveurs cette année). Ensuite les mises à jours de sécurité ne sont nécessaires que s'il y a des problèmes de sécurité. Pour un serveur de base de données accessible uniquement des serveurs web, y a pas besoin de corriger les failles.
Fabien LE LEZ
On Mon, 18 Aug 2008 16:27:44 +0200, Pierre-Hugues HUSSON :
Quand t'as une mise à jour du noyau, t'es pas obligé de rebooter, faut voir si la mise à jour te concerne.
Je ne suis pas sûr de tout comprendre. Typiquement, sur la machine (Debian Etch), je vais taper :
aptitude update && aptitude upgrade
Aptitude va alors m'indiquer que certains paquets doivent être mis à jour, dont le paquet linux-image-xxx. Je valide, et j'ai un message assez long (tout une page), qui dit en substance que le nouveau noyau a le même numéro de version que l'ancien, et qu'en conséquence, je dois rebooter la machine le plus vite possible, si je veux éviter que certains démons commencent à déconner. Donc, bête et discipliné, je redémarre la machine dès qu'aptitude a fini son travail de mise à jour.
Vu que ça fait la même chose sur une dedibox et mon serveur local, j'imagine que ce n'est pas dû à une installation foireuse.
On Mon, 18 Aug 2008 16:27:44 +0200, Pierre-Hugues HUSSON :
Quand t'as une mise à jour du noyau, t'es pas obligé de rebooter, faut voir
si la mise à jour te concerne.
Je ne suis pas sûr de tout comprendre.
Typiquement, sur la machine (Debian Etch), je vais taper :
aptitude update && aptitude upgrade
Aptitude va alors m'indiquer que certains paquets doivent être mis à
jour, dont le paquet linux-image-xxx.
Je valide, et j'ai un message assez long (tout une page), qui dit en
substance que le nouveau noyau a le même numéro de version que
l'ancien, et qu'en conséquence, je dois rebooter la machine le plus
vite possible, si je veux éviter que certains démons commencent à
déconner.
Donc, bête et discipliné, je redémarre la machine dès qu'aptitude a
fini son travail de mise à jour.
Vu que ça fait la même chose sur une dedibox et mon serveur local,
j'imagine que ce n'est pas dû à une installation foireuse.
On Mon, 18 Aug 2008 16:27:44 +0200, Pierre-Hugues HUSSON :
Quand t'as une mise à jour du noyau, t'es pas obligé de rebooter, faut voir si la mise à jour te concerne.
Je ne suis pas sûr de tout comprendre. Typiquement, sur la machine (Debian Etch), je vais taper :
aptitude update && aptitude upgrade
Aptitude va alors m'indiquer que certains paquets doivent être mis à jour, dont le paquet linux-image-xxx. Je valide, et j'ai un message assez long (tout une page), qui dit en substance que le nouveau noyau a le même numéro de version que l'ancien, et qu'en conséquence, je dois rebooter la machine le plus vite possible, si je veux éviter que certains démons commencent à déconner. Donc, bête et discipliné, je redémarre la machine dès qu'aptitude a fini son travail de mise à jour.
Vu que ça fait la même chose sur une dedibox et mon serveur local, j'imagine que ce n'est pas dû à une installation foireuse.
Nicolas George
Fabien LE LEZ wrote in message :
aptitude update && aptitude upgrade
Ben déjà, tu pourrais refuser la mise à jour du noyau à ce niveau.
l'ancien, et qu'en conséquence, je dois rebooter la machine le plus vite possible, si je veux éviter que certains démons commencent à déconner.
Pas les démons, les modules. Et seulement ceux qui ne sont pas encore chargés. En gros, tant que tu n'as pas rebooté, tu ne peux pas ajouter de nouveau matériel que tu n'as jamais utilisé depuis le dernier boot, parce que le driver ne serait pas compatible avec le noyau.
Fabien LE LEZ wrote in message
<v42ja4tniag62bd7lia631ca784oicjkte@4ax.com>:
aptitude update && aptitude upgrade
Ben déjà, tu pourrais refuser la mise à jour du noyau à ce niveau.
l'ancien, et qu'en conséquence, je dois rebooter la machine le plus
vite possible, si je veux éviter que certains démons commencent à
déconner.
Pas les démons, les modules. Et seulement ceux qui ne sont pas encore
chargés. En gros, tant que tu n'as pas rebooté, tu ne peux pas ajouter de
nouveau matériel que tu n'as jamais utilisé depuis le dernier boot, parce
que le driver ne serait pas compatible avec le noyau.
Ben déjà, tu pourrais refuser la mise à jour du noyau à ce niveau.
l'ancien, et qu'en conséquence, je dois rebooter la machine le plus vite possible, si je veux éviter que certains démons commencent à déconner.
Pas les démons, les modules. Et seulement ceux qui ne sont pas encore chargés. En gros, tant que tu n'as pas rebooté, tu ne peux pas ajouter de nouveau matériel que tu n'as jamais utilisé depuis le dernier boot, parce que le driver ne serait pas compatible avec le noyau.
Erwan David
Fabien LE LEZ écrivait :
On Mon, 18 Aug 2008 16:27:44 +0200, Pierre-Hugues HUSSON :
Quand t'as une mise à jour du noyau, t'es pas obligé de rebooter, faut voir si la mise à jour te concerne.
Je ne suis pas sûr de tout comprendre. Typiquement, sur la machine (Debian Etch), je vais taper :
aptitude update && aptitude upgrade
Aptitude va alors m'indiquer que certains paquets doivent être mis à jour, dont le paquet linux-image-xxx. Je valide, et j'ai un message assez long (tout une page), qui dit en substance que le nouveau noyau a le même numéro de version que l'ancien, et qu'en conséquence, je dois rebooter la machine le plus vite possible, si je veux éviter que certains démons commencent à déconner. Donc, bête et discipliné, je redémarre la machine dès qu'aptitude a fini son travail de mise à jour.
Vu que ça fait la même chose sur une dedibox et mon serveur local, j'imagine que ce n'est pas dû à une installation foireuse.
Non c'est du à un choix que tu as fait, peut être implicitement.
Dans une debian tu as des paquets linux-image-2.x.y-archi-etc. qui contienent les noyaux. Si tu installes un de ces paquets tu n'aura QUE desmises à jour de sécurité.
Par contre si tu as le paquet linux-image-2.6-archi, alors celui là ne contient qu'une dépendance sur le dernier noyau, et il sera mis à jour provoquant l'installation du dernier noyau.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Fabien LE LEZ <gramster@gramster.com> écrivait :
On Mon, 18 Aug 2008 16:27:44 +0200, Pierre-Hugues HUSSON :
Quand t'as une mise à jour du noyau, t'es pas obligé de rebooter, faut voir
si la mise à jour te concerne.
Je ne suis pas sûr de tout comprendre.
Typiquement, sur la machine (Debian Etch), je vais taper :
aptitude update && aptitude upgrade
Aptitude va alors m'indiquer que certains paquets doivent être mis à
jour, dont le paquet linux-image-xxx.
Je valide, et j'ai un message assez long (tout une page), qui dit en
substance que le nouveau noyau a le même numéro de version que
l'ancien, et qu'en conséquence, je dois rebooter la machine le plus
vite possible, si je veux éviter que certains démons commencent à
déconner.
Donc, bête et discipliné, je redémarre la machine dès qu'aptitude a
fini son travail de mise à jour.
Vu que ça fait la même chose sur une dedibox et mon serveur local,
j'imagine que ce n'est pas dû à une installation foireuse.
Non c'est du à un choix que tu as fait, peut être implicitement.
Dans une debian tu as des paquets linux-image-2.x.y-archi-etc. qui
contienent les noyaux.
Si tu installes un de ces paquets tu n'aura QUE desmises à jour de
sécurité.
Par contre si tu as le paquet linux-image-2.6-archi, alors celui là ne
contient qu'une dépendance sur le dernier noyau, et il sera mis à jour
provoquant l'installation du dernier noyau.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
On Mon, 18 Aug 2008 16:27:44 +0200, Pierre-Hugues HUSSON :
Quand t'as une mise à jour du noyau, t'es pas obligé de rebooter, faut voir si la mise à jour te concerne.
Je ne suis pas sûr de tout comprendre. Typiquement, sur la machine (Debian Etch), je vais taper :
aptitude update && aptitude upgrade
Aptitude va alors m'indiquer que certains paquets doivent être mis à jour, dont le paquet linux-image-xxx. Je valide, et j'ai un message assez long (tout une page), qui dit en substance que le nouveau noyau a le même numéro de version que l'ancien, et qu'en conséquence, je dois rebooter la machine le plus vite possible, si je veux éviter que certains démons commencent à déconner. Donc, bête et discipliné, je redémarre la machine dès qu'aptitude a fini son travail de mise à jour.
Vu que ça fait la même chose sur une dedibox et mon serveur local, j'imagine que ce n'est pas dû à une installation foireuse.
Non c'est du à un choix que tu as fait, peut être implicitement.
Dans une debian tu as des paquets linux-image-2.x.y-archi-etc. qui contienent les noyaux. Si tu installes un de ces paquets tu n'aura QUE desmises à jour de sécurité.
Par contre si tu as le paquet linux-image-2.6-archi, alors celui là ne contient qu'une dépendance sur le dernier noyau, et il sera mis à jour provoquant l'installation du dernier noyau.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Fabien LE LEZ
On Mon, 18 Aug 2008 20:55:18 +0200, Erwan David :
Dans une debian tu as des paquets linux-image-2.x.y-archi-etc. qui contienent les noyaux. Si tu installes un de ces paquets tu n'aura QUE desmises à jour de sécurité. Par contre si tu as le paquet linux-image-2.6-archi
J'ai effectivement le paquet linux-image-2.6-vserver-amd64, mais depuis un bon bout de temps, le noyau s'appelle linux-image-2.6.18-6-xxx. Et justement, le message indique que c'est parce que le numéro de version ne change pas, que les modules peuvent avoir du mal à s'y retrouver.
Je viens de vérifier : sur un CD-ROM datant d'août 2007, le noyau est en version 2.6.18-5. Il n'y a donc eu qu'une nouvelle version depuis (2.6.18-6). Toutes les modifications sont donc des mises à jour de sécurité ?
On Mon, 18 Aug 2008 20:55:18 +0200, Erwan David <erwan@rail.eu.org>:
Dans une debian tu as des paquets linux-image-2.x.y-archi-etc. qui
contienent les noyaux.
Si tu installes un de ces paquets tu n'aura QUE desmises à jour de
sécurité.
Par contre si tu as le paquet linux-image-2.6-archi
J'ai effectivement le paquet linux-image-2.6-vserver-amd64, mais
depuis un bon bout de temps, le noyau s'appelle
linux-image-2.6.18-6-xxx. Et justement, le message indique que c'est
parce que le numéro de version ne change pas, que les modules peuvent
avoir du mal à s'y retrouver.
Je viens de vérifier : sur un CD-ROM datant d'août 2007, le noyau est
en version 2.6.18-5. Il n'y a donc eu qu'une nouvelle version depuis
(2.6.18-6). Toutes les modifications sont donc des mises à jour de
sécurité ?
Dans une debian tu as des paquets linux-image-2.x.y-archi-etc. qui contienent les noyaux. Si tu installes un de ces paquets tu n'aura QUE desmises à jour de sécurité. Par contre si tu as le paquet linux-image-2.6-archi
J'ai effectivement le paquet linux-image-2.6-vserver-amd64, mais depuis un bon bout de temps, le noyau s'appelle linux-image-2.6.18-6-xxx. Et justement, le message indique que c'est parce que le numéro de version ne change pas, que les modules peuvent avoir du mal à s'y retrouver.
Je viens de vérifier : sur un CD-ROM datant d'août 2007, le noyau est en version 2.6.18-5. Il n'y a donc eu qu'une nouvelle version depuis (2.6.18-6). Toutes les modifications sont donc des mises à jour de sécurité ?
Erwan David
Fabien LE LEZ écrivait :
On Mon, 18 Aug 2008 20:55:18 +0200, Erwan David :
Dans une debian tu as des paquets linux-image-2.x.y-archi-etc. qui contienent les noyaux. Si tu installes un de ces paquets tu n'aura QUE desmises à jour de sécurité. Par contre si tu as le paquet linux-image-2.6-archi
J'ai effectivement le paquet linux-image-2.6-vserver-amd64, mais depuis un bon bout de temps, le noyau s'appelle linux-image-2.6.18-6-xxx. Et justement, le message indique que c'est parce que le numéro de version ne change pas, que les modules peuvent avoir du mal à s'y retrouver.
Je viens de vérifier : sur un CD-ROM datant d'août 2007, le noyau est en version 2.6.18-5. Il n'y a donc eu qu'une nouvelle version depuis (2.6.18-6). Toutes les modifications sont donc des mises à jour de sécurité ?
Sans doute, je n'ai pas suivi. Note que etch nhalf utilise un 2.6.24 pour supporter plus de matériel. Mais j'ai des etch en 2.6.18 au boulot sans aucun problème, puisque le hard ne s'est pas modernisé tout seul.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Fabien LE LEZ <gramster@gramster.com> écrivait :
On Mon, 18 Aug 2008 20:55:18 +0200, Erwan David <erwan@rail.eu.org>:
Dans une debian tu as des paquets linux-image-2.x.y-archi-etc. qui
contienent les noyaux.
Si tu installes un de ces paquets tu n'aura QUE desmises à jour de
sécurité.
Par contre si tu as le paquet linux-image-2.6-archi
J'ai effectivement le paquet linux-image-2.6-vserver-amd64, mais
depuis un bon bout de temps, le noyau s'appelle
linux-image-2.6.18-6-xxx. Et justement, le message indique que c'est
parce que le numéro de version ne change pas, que les modules peuvent
avoir du mal à s'y retrouver.
Je viens de vérifier : sur un CD-ROM datant d'août 2007, le noyau est
en version 2.6.18-5. Il n'y a donc eu qu'une nouvelle version depuis
(2.6.18-6). Toutes les modifications sont donc des mises à jour de
sécurité ?
Sans doute, je n'ai pas suivi. Note que etch nhalf utilise un 2.6.24
pour supporter plus de matériel. Mais j'ai des etch en 2.6.18 au boulot
sans aucun problème, puisque le hard ne s'est pas modernisé tout seul.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Dans une debian tu as des paquets linux-image-2.x.y-archi-etc. qui contienent les noyaux. Si tu installes un de ces paquets tu n'aura QUE desmises à jour de sécurité. Par contre si tu as le paquet linux-image-2.6-archi
J'ai effectivement le paquet linux-image-2.6-vserver-amd64, mais depuis un bon bout de temps, le noyau s'appelle linux-image-2.6.18-6-xxx. Et justement, le message indique que c'est parce que le numéro de version ne change pas, que les modules peuvent avoir du mal à s'y retrouver.
Je viens de vérifier : sur un CD-ROM datant d'août 2007, le noyau est en version 2.6.18-5. Il n'y a donc eu qu'une nouvelle version depuis (2.6.18-6). Toutes les modifications sont donc des mises à jour de sécurité ?
Sans doute, je n'ai pas suivi. Note que etch nhalf utilise un 2.6.24 pour supporter plus de matériel. Mais j'ai des etch en 2.6.18 au boulot sans aucun problème, puisque le hard ne s'est pas modernisé tout seul.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Fabien LE LEZ
On 18 Aug 2008 18:25:30 GMT, Nicolas George <nicolas$:
aptitude update && aptitude upgrade
Ben déjà, tu pourrais refuser la mise à jour du noyau à ce niveau.
Certes. Jusqu'ici, je me disais que si une Debian stable m'encourage à mettre le noyau à jour, c'est qu'il y a une raison. S'il s'agit bien de mises à jour de sécurité, tout le monde ne devrait-il pas les appliquer (et rebooter pour charger le nouveau noyau), même ceux (comme Luc) qui compilent leur noyau eux-mêmes ?
On 18 Aug 2008 18:25:30 GMT, Nicolas George
<nicolas$george@salle-s.org>:
aptitude update && aptitude upgrade
Ben déjà, tu pourrais refuser la mise à jour du noyau à ce niveau.
Certes. Jusqu'ici, je me disais que si une Debian stable m'encourage à
mettre le noyau à jour, c'est qu'il y a une raison.
S'il s'agit bien de mises à jour de sécurité, tout le monde ne
devrait-il pas les appliquer (et rebooter pour charger le nouveau
noyau), même ceux (comme Luc) qui compilent leur noyau eux-mêmes ?
On 18 Aug 2008 18:25:30 GMT, Nicolas George <nicolas$:
aptitude update && aptitude upgrade
Ben déjà, tu pourrais refuser la mise à jour du noyau à ce niveau.
Certes. Jusqu'ici, je me disais que si une Debian stable m'encourage à mettre le noyau à jour, c'est qu'il y a une raison. S'il s'agit bien de mises à jour de sécurité, tout le monde ne devrait-il pas les appliquer (et rebooter pour charger le nouveau noyau), même ceux (comme Luc) qui compilent leur noyau eux-mêmes ?
Nicolas S.
Fabien LE LEZ a écrit:
Certes. Jusqu'ici, je me disais que si une Debian stable m'encourage à mettre le noyau à jour, c'est qu'il y a une raison. S'il s'agit bien de mises à jour de sécurité, tout le monde ne devrait-il pas les appliquer (et rebooter pour charger le nouveau noyau), même ceux (comme Luc) qui compilent leur noyau eux-mêmes ?
Idéalement, si. En pratique, télécharger, installer et redémarrer un nouveau noyau présente aussi des inconvénients, surtout quand on sait que les fix de sécurité ne sont pas facilement exploitables ou qu'ils ne nous concernent pas du tout.
Pour ceux comme Luc et moi qui compilons nous-mêmes nos noyaux, l'option CONFIG_LOCALVERSION permet d'éviter ce genre de désagréments.
-- Nicolas S.
Fabien LE LEZ a écrit:
Certes. Jusqu'ici, je me disais que si une Debian stable m'encourage à
mettre le noyau à jour, c'est qu'il y a une raison.
S'il s'agit bien de mises à jour de sécurité, tout le monde ne
devrait-il pas les appliquer (et rebooter pour charger le nouveau
noyau), même ceux (comme Luc) qui compilent leur noyau eux-mêmes ?
Idéalement, si. En pratique, télécharger, installer et redémarrer un
nouveau noyau présente aussi des inconvénients, surtout quand on sait
que les fix de sécurité ne sont pas facilement exploitables ou qu'ils
ne nous concernent pas du tout.
Pour ceux comme Luc et moi qui compilons nous-mêmes nos noyaux, l'option
CONFIG_LOCALVERSION permet d'éviter ce genre de désagréments.
Certes. Jusqu'ici, je me disais que si une Debian stable m'encourage à mettre le noyau à jour, c'est qu'il y a une raison. S'il s'agit bien de mises à jour de sécurité, tout le monde ne devrait-il pas les appliquer (et rebooter pour charger le nouveau noyau), même ceux (comme Luc) qui compilent leur noyau eux-mêmes ?
Idéalement, si. En pratique, télécharger, installer et redémarrer un nouveau noyau présente aussi des inconvénients, surtout quand on sait que les fix de sécurité ne sont pas facilement exploitables ou qu'ils ne nous concernent pas du tout.
Pour ceux comme Luc et moi qui compilons nous-mêmes nos noyaux, l'option CONFIG_LOCALVERSION permet d'éviter ce genre de désagréments.
-- Nicolas S.
Nicolas George
Fabien LE LEZ wrote in message :
S'il s'agit bien de mises à jour de sécurité, tout le monde ne devrait-il pas les appliquer
La réponse t'a déjà été donnée plus haut : toutes les failles de sécurité ne concernent pas toutes les configurations, loin de là.
Par exemple, tout à l'heure, il y a eu une alerte pour Postfix. Mais l'alerte précisait les conditions : /var/mail en écriture publique et possibilité de faire un lien dur vers un fichier privilégié. Sur les machines que j'administre, /var/mail n'est en écriture que pour le groupe mail (c'est la config par défaut), et sur une partition séparée (donc pas le liens durs). Je n'ai donc pas besoin d'upgrader Postfix toutes affaires cessaites. Je l'upgraderai, bien sûr, mais quand ce sera commode pour moi.
Pour le noyau, c'est pareil : la plupart des upgrades concernent des failles dont l'impact est très faibles, principalement des DoS locaux (un utilisateur local peut crasher la machine, ce qui le fait autant chier lui que les autres) sous certaines conditions particulières.
Fabien LE LEZ wrote in message
<5epja4pqkhmbgdvj0cpijgpdoectr6mjh7@4ax.com>:
S'il s'agit bien de mises à jour de sécurité, tout le monde ne
devrait-il pas les appliquer
La réponse t'a déjà été donnée plus haut : toutes les failles de sécurité ne
concernent pas toutes les configurations, loin de là.
Par exemple, tout à l'heure, il y a eu une alerte pour Postfix. Mais
l'alerte précisait les conditions : /var/mail en écriture publique et
possibilité de faire un lien dur vers un fichier privilégié. Sur les
machines que j'administre, /var/mail n'est en écriture que pour le groupe
mail (c'est la config par défaut), et sur une partition séparée (donc pas le
liens durs). Je n'ai donc pas besoin d'upgrader Postfix toutes affaires
cessaites. Je l'upgraderai, bien sûr, mais quand ce sera commode pour moi.
Pour le noyau, c'est pareil : la plupart des upgrades concernent des failles
dont l'impact est très faibles, principalement des DoS locaux (un
utilisateur local peut crasher la machine, ce qui le fait autant chier lui
que les autres) sous certaines conditions particulières.
S'il s'agit bien de mises à jour de sécurité, tout le monde ne devrait-il pas les appliquer
La réponse t'a déjà été donnée plus haut : toutes les failles de sécurité ne concernent pas toutes les configurations, loin de là.
Par exemple, tout à l'heure, il y a eu une alerte pour Postfix. Mais l'alerte précisait les conditions : /var/mail en écriture publique et possibilité de faire un lien dur vers un fichier privilégié. Sur les machines que j'administre, /var/mail n'est en écriture que pour le groupe mail (c'est la config par défaut), et sur une partition séparée (donc pas le liens durs). Je n'ai donc pas besoin d'upgrader Postfix toutes affaires cessaites. Je l'upgraderai, bien sûr, mais quand ce sera commode pour moi.
Pour le noyau, c'est pareil : la plupart des upgrades concernent des failles dont l'impact est très faibles, principalement des DoS locaux (un utilisateur local peut crasher la machine, ce qui le fait autant chier lui que les autres) sous certaines conditions particulières.
