Reprise du message précédent :

ce a quoi répond l'auteur de pax :

édit :
de surcroit ce n'est pas tout /proc qui est restreint avec grsec mais certaines parties

bonjour !
 
J'ai voulu telecharger le noyau 2.6.7 mais la date indique qu'il date de juin... et donc il n'est pas mis a jour pour les  patch de sécu ? (sur kernel.org)

non il ne l'ai pas .
cf : http://www.isec.pl/vulnerabilities [...] cleaks.txt
(d'ailleurs au final je suis repassé en 2.4 sur ma gate )

 
non, il te faut le 2.6.8-rc2 ou rc3 pour ça il me semble

rc3

le procleak truc est corrigé dans le rc3?

juste une question: comment vous faites pour vos serveurs en prod ? pire encore, s'ils sont hébergés ailleurs ... et si en refaisant un kernel et en rebootant, et que ça ne reboote plus
je serais vraiment intéressé de connaitre votre méthode... paske au rythme de toutes ces failles, nous qui allions migrer de freebsd vers linux, bin la c chaud qd meme

ah bon ??
 
j ai pas reussi a executer le truc pourtant

je n'ai pas testé , c'est un des auteurs du patch grsec qui l'as dis , je lui fait donc confiance

bizarre moi le truc marchait pas

?

si ca reboot plus... bin on a conserver notre ancien kernel, alors on reboot sur l'ancien

ouais mais si c hébergé chez va savoir qui et qu'il faut vraiment se galérer pour y aller ....

 
même si c'est hébergé, avoir le root accès sur la machine c'est suffisant, tout se fait à distance

 
tu reboots à distance une machine plantée sur un kernel panic toi ? .... va falloir que tu m'expliques comment tu fais ça

il y a une option pour ça il me semble ; reboot auto après un kernel panic
 
EDIT : j'ai retrouvé

 
http://www.linuxjournal.com/article.php?sid=2365
 
fichier /proc/sys/kernel/panic

ah oui exact
ouai mais comment lui faire booter sur un autre kernel a distance dans ce cas ? tu peux pas choisir ton noyau sur grub via le réseau, si ?  

il me semble qu'il y a moyen sous lilo de lui dire boot une seule fois sur ce kernel pis si ça couille boot sur un autre mais je me souviens pas ou j'ai lu ça
en tout cas c intéressant tout ça si vous avez plus d'infos !

l'idée, c'est de garder par défaut ton ancien noyau et lorsque tu veux rebooter sur ton nouveau noyau, utiliser les options pour forcer le boot d'un noyau donné (lilo -R par ex)

 
ça non ? (man lilo)
 

c'est quoi ce rc4 tout petit qui est déjà sortit là !  
apparemment le prochain sera le 2.6.8 final

2.6.8 ^^

 
oué, l'erreur de merde en nfs, un '!' en trop, qui était déjà corrigé, c'est malin !

que des bouley

 
y-en a qui sont pas content sur la lkml ... ça fait mauvais genre pour une release ... y-en a qui voudrait même un 2.6.9 pour l'occasion

rofl moi qui venait de me le compiler le 2.6.8
 
meme si j'utilise rien de nfs, je vais le compiler pour pouvoir poster 2.6.8.1 dans le topic uname

 
tu peux faire ça sans recompiler  

 
jsuis pas un menteur mouuuuuua  

au sujet des kernels preemptibles :
un bon lien pour expliquer l'état actuel du noyau en la matière :
http://www.mvista.com/dswp/PreemptibleLinux.pdf
 
une fonctionnalité débatu sur la lkml ces temps ci et qui prend forme :
http://people.redhat.com/mingo/vol [...] ry-preempt
le thread :
http://lkml.org/lkml/2004/8/15/42
 
vais m'essayer ça

moi mes irq ils sont gérés dans un thread chacun

c'est top moumoutte dis donc

 
bah ça évite les locks à la con donc mon système est plus réactif  

udok ? tu fais cela grace a quel patch et sur quel noyaux ?

c une blague ou quoi ?  
j'ai mis tous les liens utiles 2 posts plus haut

 dzolé

ton liens sur l etat actuel , parle de 2.4 . Comme jsuis pas un grand connaisseur , pourrais tu m explique vulgairement si l option preemptible dispo en std sur le 2.6.8 permet des latences du meme ordre que le 2.4 a savoir entre 10 et 60 micro sec.
   

non, d'où l'interet du 2eme lien
en même temps le 10-60 pour le 2.4 n'est qu'à titre indicatif, les méthodes qui avaient été utilisé pour mesurer ça à l'époque n'était pas bonne
en utilisant les même méthode on trouvait des pointes à seulement 50ms pour le 2.6 alors qu'avec la méthode actuelle c'est parfois plusieurs 100aines de ms
mais ils y travaillent pour baisser ça

en appliquant preemptible + voluntary preemp ? ou voluntary seul ?
 
niveau apic ? activé ou pas ?

 
apic non activé
pour le reste, ça manque de doc, et j'ose pas posé la question sur la lkml
ils l'ont surement dit sur le thread mais il est tellement énorme que malgré mon effort pour tout lire, il m'en manque qq'bout
donc j'ai laissé par défaut : preempt désactivé (mais compilé quand même), et volontary sur 3 (ça se regle dans /proc tout ça)
quand c'est sur 3 ça donne des hard interrupt threadé (alors qu'en 2, seule les soft interrupt sont threadé si j'ai bien compris), mais par contre c'est pas très stable chez tout le monde dans ce cas
j'essaierais bien d'activé le preempt pour voir ... mais sans plus de doc, je me tatte un peu
d'autant que c'est encore en cours de devel donc je pense pas que le devel apprécierait les question à la con des utilisateurs

http://lkml.org/lkml/2004/8/17/53
bientot le reiser4 dans le kernel
en fait je m'en fous, je vois même pas l'interet du reiser4  

 
Si c'est aussi performant que le 3.6, sa durée d'utilisation n'excédera pas 30 minutes chez moi