Reprise du message précédent :
Et pour un serveur X11 est très loin d'être obligatoire

Sauf si c'est un serveur d'applications où il faut au minimum le client X11 (mais je crois qu'à cause des dépendances ça oblige à installer le server X11 également)

Bien entendu, je réagissais sur le "strict minimum pour un serveur"

ouep tout a fait, merci pour vos conseils

Pour info :
Dell m1330 et ubuntu, c'est fait :
http://www.matbe.com/actualites/co [...] /?page=1#1

Oui sauf qu'ici c'est le topic Debian, alors faut pas rester là, hein

Vous avez déjà essayé la partition root en drbd ?  
 
Samarche tousseul avec update-initramfs quand y'a le module ?

J'ai du mal à capté l'interêt d'avoir le root en drbd  

Pourquoi root et pas juste les données tu veux dire ?  
Parce que le serveur est déjà en production et fonctionne avec des outils qu'il n'est pas envisageable de modifier

Oui mais le serveur en face, il va juste synchroniser sur une partition qui ne sera pas root pour lui alors, c'est ça ?

Mais si tu mets root sur le drbd, faudra bien deplacer les données à un moment donné et le relancer, donc je vois pas trop pourquoi se prendre la tête en fait

Le but serait d'avoir une réplique intégrale du serveur, root étant un volume drbd utilisant les disques de chaque serveur et /boot carte CF.
De cette manière, avec heartbeat, il devrait être possible de gérer le failover et la reconstruction de manière totalement automatique et transparente pour les users.
 
Si c'est possible ...

Oui mais non
 
Parce que la synchro drbd se fait entre deux serveurs, faut que les deux soit lancés, or un seul peut avoir accès à ta partoche drbd, donc problème si la partoche en question est / ...
 
Ou alors tu parles de drbd2 avec un système de fichiers clusterisé, mais perso je ne mettrais pas ca en production, c'est pas assez stable.

Je vois pas le problème.  
Si mon serveur principal tombe, la réplique devient maître, monte la partition root et choppe l'ip virtuelle du cluster. Dès que l'ancien principal revient, il resync, et le système est prêt pour un nouveau cycle.
Si ma réplique tombe, elle resync au retour.

Le contenu de ce message a été effacé par son auteur

Le problème il est la, pour que la réplique puisse devenir maitre, elle doit deja tourner, en parallèle, mais si c'est la partition root qui est synchronisé, elle fait comment pour "tourner" en tant que réplique ?

Suffit que l'initrd se charge du heartbeat et de drbd
Pour démarrer le cluster, il faut dire à une node "deviens master" et faire un resync sur les autres. Dans le cadre d'un système embarqué c'est pas un problème.

Si tu as une meilleure solution, aide moi

Edit: Pour ceux que ça intéresse, j'ai résolu le problème en utilisant drbd/heartbeat avec un vserver

Bon même si ça peut paraître trivial je pose quand même la question : "comment remonter un bug ?"
 
Parce que là je suis quasiment sûr d'en avoir trouvé un joli sur testing mais je sais pas où remonter l'info et j'ai peur de faire un doublon.  
 
Voilà à votre bon coeur messieurs dames.

Tu lances un shell => reportbug
 
Eventuellement tu regardes sur http://packages.debian.org que le bug a pas déja été remonté.

google + "debian bug", premier lien
http://www.debian.org/Bugs/

Question bête, les bugs qui ne viennent pas du packaging debian mais viennent du logiciel lui-même sot bien remontés aux auteurs du logiciel ?

normalement oui. Le mainteneur du paquet est censé remonter le problème

Certains développeurs demandent même à ce que les bugs provenant d'un paquet passent uniquement par le gestionnaire de bug de la distrib, et c'est les mainteneurs des-dits paquets qui forwardent ensuite aux développeurs.

 
 
C'est le cas chez Debian ; les bugs sont taggués "upstream" (amont), forwarded" (transmis en amont) et "fixed-upstream" (réglés en amont).

Petite question technique.
J'utilise nfs v4 sur un serveur doté d'un Pentium Dual Core (archi Core 1.6Ghz, entre nous, ça dépote bien pour ce que ça coûte ).
Bon voilà, nfs est utilisé pour transférer des gros fichiers (quelques Go). Lors du transfert, nfs à l'air de créer plusieurs threads, qui prennent chacun environ 15% de CPU.

"Problème" : mon coeur 1 est à 100%, ce qui "limite" la copie à 20mo/s, tandis que mon autre coeur est à seulement quelques % d'utilisation.
Comment équilibrer la charge sur les deux CPU ?

Indices :
$ uname -a
Linux bravo 2.6.22-3-686 #1 SMP Mon Nov 12 08:32:57 UTC 2007 i686 GNU/Linux

Réseau Gigabit des deux cotés, machine encore plus puissante de l'autre coté (Core 2 Duo E6400@3.2Ghz)

edit : petite illustration des multiples threads avec un top :

2666 root      15   0     0    0    0 R    5  0.0   0:17.62 nfsd                                                                              
 2668 root      15   0     0    0    0 D    3  0.0   0:15.26 nfsd                                                                              
 2665 root      15   0     0    0    0 S    3  0.0   0:16.64 nfsd                                                                              
 2663 root      16   0     0    0    0 S    3  0.0   0:15.55 nfsd                                                                              
 2667 root      16   0     0    0    0 R    3  0.0   0:16.62 nfsd                                                                              
 2664 root      15   0     0    0    0 S    2  0.0   0:16.42 nfsd                                                                              
 2670 root      15   0     0    0    0 R    2  0.0   0:16.98 nfsd                                                                              
 2669 root      15   0     0    0    0 D    1  0.0   0:15.64 nfsd  

Chez moi 50% c'est 1 coeur à fond, 100% ce sont les 2 coeurs à fond  

Ben là j'ai bien 100% sur un coeur, et 4 ou 5 % sur l'autre...

Ce que je veux dire, c'est que j'ai l'impression que ça bride le transfert, puisque nfsd n'a pas l'air de lancer de thread supplémentaire sur l'autre coeur, mais c'est une hypothèse. Le must aurait été deux coeurs à 50% chacun (edit : ce qui éviterai des pics à 100% sur un coeur qui limiterai le transfert).
M'enfin je comprend pas trop, d'où ma question en fait

Tu n'as pas affiché la légende des colonnes mais par dfaut sur top l'utilisation  CPU c'est la 4 ème colonne en partant de la droite et ça n'illustre pas ton problème et quel est le logiciel que tu utilise pour l'occupation  CPU  totale

htop

edit : sur mon copié coller, c'est bien la colonne avec les chiffres 5, 3, 2 et 1

edit : je vais en cours là, je pourrai répondre cette aprem

Apparement c'est le driver réseau qui doit accaparer tout le temps processeur, en gros il doit être codé avec les pieds. Quelle carte réseau/driver ? (le voir avec lspci/lsmod)

A part avec nfs les transferts sont normaux ? C'est pas ton disque qui se serait mis en PIO ?
 
Sinon c'est un pentium ou un core au final ?

 
Rigolez pas, c'est une realtek (rtl8169 un truc du genre, je vérifie en rentrant)  
 

 
Les transfert disque à disque sans passer par le réseau sont normaux (pas de PIO donc). A chaque fois que je passe par le rézal, c'est pas top (ssh idem, même un peu la cata, car 5Mo/s seulement !).
J'ai un switch en rab pour vérifier, mais déjà le coup de l'occupation CPU me pose question.
 
Sinon, c'est un Pentium "nouveau", c'est à dire architecture Core mais avec moins de cache (donc c'est un Pentium et un Core )

J'imagine que c'est un E2140 ou 2160, des Core2Duo allégé en cache mais denommés Pentium. Super la stratégie de nommage d'Intel d'ailleurs sur ce coup, pour embrouiller les gens y a pas mieux.

J'ai un T2060,  Core1 Duo allégé en cache et je n'ai aucun problème de transferts réseaux, je pense que ça vient du driver (realtek en plus il me semble que leurs drivers avaient quelques problèmes)

Bon, j'ai fait du gros caca sur ma debian (mais bien comme il faut)
J'ai voulu la passer de "etch" stable en testing donc j'ai viré les sources de etch pour mettre ceux de testing puis j'ai fait apt-get update puis apt-get upgrade et en fait ça m'a viré plein de trucs (gedit et tout le toutim)
Format > reinstall ?

Bon, je viens de retester sur des gros fichiers en SSH : 25Mo/s, soit plus vite que le NFS...

edit : et CPU jamais à 100%, les deux coeurs se partagent bien la charge ! (50/50)

conclusion : NFS merde

Si tu as accès à un shell, non, je vois pas de raison de réinstaller

La preuve que aptitude c'est mieux que apt-get    
 
Bon bin la prochaine fois que tu fera un dis-upgrade tu verifieras mieux la liste de ce qu'il désinstalle    
 
Sinon il y a un log des opérations aptitude/apt-get/dpkg dans /var/log il suffit de reinstaller ce qui a été supprimé

 
Oui c'est le cas
 

 
Vais voir ça
Mais y'a pas moyen de bien tout mettre en testing sans que ça me fasse un caca anal ?
(et aussi j'aimerais bien faire tourner compiz)