Reprise du message précédent :

Une noobuntu 9.04

 
Edit : oO il n'est ni à l'heure ni à la bonne date...

Heu, c'est la date et l'heure de compilation du kernel, pas l'heure de maintenant  

Ça sent le kernel générique de Debian  

hop là    
 

Et derechef :
 

je disais sur le topic kernel
et hop

Faut quand même bien dire qu'ici, c'est le topic le plus useless d'OSA. Ca à presque autant d'intérêt qu'un topic "Qu'avez-vous mangé au ptit déj ?"

ouep on commence à savoir à quoi ressemble un uname linux (95% du topic)

Fait ce matin
 

 
Encore un peu de graphisme dessus et il sera très bieng

[patrick@localhost ~]$ uname -a
Linux localhost 2.6.30-desktop-1mnb #1 SMP Fri Jun 12 03:32:31 EDT 2009 i686 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
[patrick@localhost ~]$

Gné ? sa tourne encore ?

Faut croire :
 
12:43:15 up 578 days, 20:28,  1 users,  load average: 0.81, 0.33, 0.22

T'as pris visiblement le .config de arch puis compilé sous debian. T'as retouché la config de arch avant de compiler ou alors tu l'as pris tel quel?
Parce qu'il y a beaucoup de choses qui peuvent être compilé en modules alors qu'ils sont intégrés dans le noyau. De mémoire, il y a aussi 2 optimisations qui ne sont pas cochées comme:
- optimisation for size
- Allow gcc to uninline functions marked
Ces 2 options réduisent sensiblement la taille du noyau.

 
nan nan du tout, c est bien une arch complete,
Lenny est juste le hostname, concours de circonstance. J étais sur mon ancien PC en lenny debian, mais j ai gardé lenny opur le host donc. Rien d autre!

Ah Ok!  
Le mélange fait bizarre

 
ouais mais pour un pauvre serveur domestique dont l'architecture date de 2002 (j'ai trouvé 1er octobre 2002) ca suffit amplement !

J'ai la même chose chez moi
La flemme de compiler mon kernel, c'est pas un serveur de prod.

Et surtout en prod, pourquoi vouloir absolument compiler son kernel  

À part perdre le support officiel de sa distro et être toujours à la bourre sur les updates ...
(sauf si besoin précis non couvert par les kernels proposés, évidemment)

Je pensais surtout à ça

En prod, les updates de kernels sont loin d'être importantes. Encore faut-il pouvoir rebooter la machine pour les appliquer. Puis les failles de sécu sont surtout dans les services et le besoin de les corriger dépend de l'exposition du server. Sans parler du fait que t'es jamais sûr de ce qui pourrait casser suite à l'update (et que c'est toujours quand c'est capital de minimiser le down time que tout part en sucette ).

Je suis bien d'accord, mais ça n'empêche, que sauf besoin non couvert par un des kernels stock, quel est l'intérêt de vouloir à tout prix compiler sa kernaille ?
 
J'aurais plutôt tendance à me baser sur quelque chose d'éprouvé et de supporté officiellement.

Franchement, j'ai jamais vu un admin jouer au geek avec des servers de prod.
Ce que je voulais dire c'est que des machines de prod avec un kernel qui date du jour de l'installation, ça court les rues. Tant qu'il n'y a pas de problème concret, personne ne prend le risque d'y toucher.

Bientôt une maj .

[patrick@localhost ~]$ uname -a
Linux localhost 2.6.30-desktop-2mnb #1 SMP Thu Jun 18 20:41:35 EDT 2009 i686 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
[patrick@localhost ~]$  
 

Petit essai d'install de NetBSD 5.0 comme DomU Xen en PV (derrière Xen 3.2-1 et un Dom0 Debian Lenny) :

Mise a jour  
[splissken@SPFreeBSD ~]$ uname -a
FreeBSD SPFreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu Jun 25 07:47:36 CEST 2009     splissken@SPFreeBSDusr/obj/usr/src/sys/GENERIC  i386
[splissken@SPFreeBSD ~]$

Linux archa1 2.6.30-ARCH #1 SMP PREEMPT Fri Jun 19 21:25:17 UTC 2009 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux

NetBSD 5.0 patché pour puce wifi atheros et acceleration graphique sur eeePC 701 4G
 
SPeeeNetBSD$ uname -a
NetBSD SPeeeNetBSD.SP.net 5.0.0_PATCH NetBSD 5.0.0_PATCH (KERNSP) #0: Mon Jun 29 23:34:52 CEST 2009  splissken@SPeeeNetBSD.SP.netmnt/archos/usr/obj/sys/arch/i386/compile/KERNSP i386
SPeeeNetBSD$

Clairement, sur les serveurs en prod' les mises à jour effectuées au niveau du noyau sont quasiment effectuées au cas par cas ; plusieurs paramètres entrent en ligne de compte :
 
1) gravité de la mise à jour (raf des maj de pilotes ou fonctionnalités sauf si ça corrige des bugs qui impactent l'exploitation)
2) exposition du serveur (si le serveur est public / accessible depuis l'extérieur, difficile de faire l'impasse sur les maj de sécu, notamment de type 'privilege escalation')
3) support du matériel (certaines maj ont pour effet d'entrainer des regressions à ce niveau, donc beware)
 
Dans ma boîte, par exemple, si je me souviens bien, le plus large déploiement d'une mise à jour du noyau ne concernant pas la sécu portait en fait sur une nouvelle version corrigeant un bug majeur dans NFS.
 
 

   
 
Cela dit, nous utilisons nous propres images d'installation CentOS avec des noyaux compilés et adaptés aux différents type de serveurs en exploitation (à ce niveau, c'est du rock-solid / super-testé) ; pour les autres distributions (RedHat Enterprise ou Debian stable, principalement, ce sont les versions officielles, sans modification, qui sont utilisées -notamment pour des questions de support / mise à jour).
 
Pour les machines à usage interne uniquement, c'est vraiment très rare de les mettre à jour / rebooter une fois qu'elles sont entrées en prod' ; par exemple :

 
Comme on voit plus beaucoup d'anciennes versions de Linux depuis quelques temps, j'en ai profité  
 
Je ne poste pas leur uptime, car sur ces versions ce n'est pas représentatif en raison d'une limitation au niveau du compteur 'jiffies' qui fait que l'uptime reboucle sur 0, passé 497 jours (en réalité, les 3 premiers serveurs ont tous une durée de fonctionnement sans reboot supérieure à 800 jours au minimum, si je me plante pas)... Pour des raisons de confidentialité, vous noterez que je n'étais pas en mesure de publier leur hostname, vous m'excuserez.

Passage en 2.6.30 sur le serveur perso o/
 

Snow Leopard 10A402
 

 
NAS Syno
 

Leopard
 

Debian Lenny sur une HP Visualize B132L+ :
(l'image correspond à une B160L, mais l'apparence est strictement la même)

Pas tout simple, surtout le boot de l'install par réseau et les tatonnements pour le partitionnement, mais j'y suis arrivé  

Et j'en ai une plus grosse (HP Visualize B2000) dont je vais m'occuper dans quelques jours  

Tiens, j'aimerais bien tester des machins comme ça avec des archi pas communes

 
idem sous debian avec le buildserver d'alioth