Red Hat en a marre de payer pour des prunes...

JKB wrote:

marche sans problème .... idem pour les cluster de calcul ...

Et alors ? Je n'ai jamais dit que cela ne fonctionnait pas. Je
prétends simplement que les RedHat sont des m*rdes à administrer
depuis la version 8.

je ne suis qu'utilisateur :-)

mais sans le support redhat ( que nous n'avons jamais utilisé
d'ailleurs) , personne n'aurait
signé pour mettre du linux sur des machines clientes alors que la
solution de facilité aurait
été windows.

À voir (pour la solution de facilité). Et je sais de quoi je parle
;-)

JKB

dans notre contexte, il a vraiment fallu se "battre" pour imposer linux sur
les clients en remplacement des SGI ...

le point dur a été la bureautique et Exchange => point qui n'a
d'ailleurs pas été résolu !!

on a fini par acheter des pc sans écran qu'on partage avec un switch ...

la solution de facilité aurait donc bien été windows dans notre cas => 1
seule UC au lieu de 2 ...

Emmanuel Florac wrote:

experience perso => nous utilisons au taf des rhel 3 sur des postes
clients ( calcul scientifique ) et ça marche sans problème .... idem
pour les cluster de calcul ...

Bien sûr. Le problème c'est que les Fedora sont nulles, et pour les RHEL
il n'y a aucune source officielle d'applications parfois très utiles
voire nécessaires. En soi ce n'est pas mauvais, mais comparé aux autres
distributions ça fait franchement pitié.

le seul truc qu'on a compilé , c'est MPI ... le reste c'est du proprio
très cher donc
on ne va pas en plus se gauffrer la compilation :-)

Pour le poste de travail n'en parlons pas, un poste de travail qui ne peut
ni lire un mp3 ni un windows media, ni afficher une page web avec du
flash, c'est proche de l'escroquerie.

yum install mplayer + codecs + install du plugin flash pour firefox ...
2 minutes montre en main ..
arrête la mauvaise foi :-)

JKB <knatschke@koenigsberg.fr> wrote:

Pendant plus de 10 ans on a eu un serveur Sun comme serveur NFS du labo, avec
des clients de toutes sorte, y compris Sun,HPUX, Linux et BSD, des serveurs X en
pagaille, etc. sans jamais aucun problème, y compris pour les locks.

Dis... Ton diplôme t'empêche-t-il de lire correctement ? Je ne parle

Tu attrapes la Stéphanite toi aussi! Un suffit amplement.
Je ne parle que de NFS, parceque franchement les problèmes de xdmcp
j'en ai rien à foutre. Comme je t'ai dit, on a eu jusqu'à une trentaine de
terminaux X qui sont partis depuis longtemps à la poubelle, donc le xdm
j'ai déjà donné, je ne veux plus en entendre parler. Heureusement les PC
indépendants sous Linux, ça résout ce problème, ça offre un affichage décent,
avec des fontes correctes et une vitesse raisonnable.

pas que du NFS (c'est une obsession chez toi, on dirait), mais de
tous les autres trucs qui font que plusieurs systèmes cohabitent
bien. Solaris avec Linux, c'est plutôt l'entente cordiale que
l'alliance à tout va. Je cherche toujours une solution pour attaquer
un poste Linux faisant du xdmcp à partir d'un poste Solaris 9 (et
j'ai blindé Solaris avec les fontes X de Linux, configuré les fontes
Solaris au travers de xfs tournant sur le poste Linux, demandé au
support de Sun... J'attends toujours la réponse !...)

Je ne comprends rien à ton problème. Pour avoir un bon affichage il faut des
fontes truetype de bonne qualité, comme les fontes Microsoft ou Bitstream Vera
et utiliser la librairie freetype2 avec le support du "hinting" qui se trouve
dans ces fontes. Il faut évidemment que tes programmes fassent appel à
freetype2 pour afficher les dites fontes. C'est le cas sous Linux, FreeBSD,
etc. sous Solaris je n'en sais absolument rien, mais si ce n'est pas le cas
rien n'empêche de recompiler entièrement xorg et les clients pour la machine.
D'ailleurs il y a une distribution basée sur le noyau Solaris et l'userland
Gnome qui s'appelle Nexenta. J'avais essayé le cdrom live, c'était trés
chouette.Quand on tournait sous Sun on n'utilisait *jamais* ni le serveur X
ni les clients venant avec SunOS, tout était recompilé aux bons soins de
Pierre David. Et idem sous HP-UX.

Je vais certainement dire une connerie, mais le support NFS est dans
le noyau. Si le noyau est patché par RedHat, tu changes le noyau
pour un officiel et on n'en parle plus. Maintenant, je maintiens

Oui le support est dans le noyau, et le responsable informatique ne veut pas
entendre parler de quoi que ce soit tel que changement de noyau ou tout autre
changement non standard. Il veut mettre le cdrom de Fedora et rien d'autre.
Quand on a 100 machines à tenir à jour, je ne peux pas lui donner tort.

Cataplasme sur une jambe de bois. Lorsqu'on corrige un truc, on
corrige la cause et non la conséquence. Je serais curieux de voir la
différence de conf, parce qu'il y en a forcément une.

En effet il y en a une, mutt -v affiche la configuration, et on voit
facilement qu'il n'y a pas de support de dotlock sous Fedora alors qu'il y est
sous Debian. Evidemment c'est le genre de chose qu'on remarque une fois qu'on
a trouvé la solution.

Et regarder de près le fichier /etc/exports du serveur ? Et les
options de montages automatiques des clients (le cas échéant) ? Les
problèmes sont presque toujours là.

La mbox est bien rw, il n'y a aucun problème pour effacer le courrier avec un
autre programme que mutt, par exemple avec mail. C'est bien là que ça a
commencé à devenir intriguant. Il a fallu que je me tape de lire le code
source pour voir que mutt *déclare* la mbox ro s'il n'arrive pas à la
verrouiller avec flock() par exemple, mais surtout, ce que je n'ai pas vu tout
de suite, avec dotlock quand il est configuré dans mutt. (Evidemment elle
reste tout ce qu'il y a de plus rw, uniquement de façon interne il la
traîte comme ro, voir mx.c et dotlock.c dans le source).

JKB

--

Michel TALON

JKB <knatschke@koenigsberg.fr> wrote:

mais sans le support redhat ( que nous n'avons jamais utilisé
d'ailleurs) , personne n'aurait
signé pour mettre du linux sur des machines clientes alors que la
solution de facilité aurait
été windows.

À voir (pour la solution de facilité). Et je sais de quoi je parle
;-)

JKB

Pour une fois je suis d'accord à 100%, d'ailleurs quand j'entends parler de
machines de calcul et de Windows dans la même phrase je me demande si on n'a
pas affaire à un fou furieux.


--

Michel TALON

Le 08-04-2006, à propos de
Re: Red Hat en a marre de payer pour des prunes...,
Michel Talon écrivait dans fr.comp.os.linux.debats :

JKB <knatschke@koenigsberg.fr> wrote:

Pendant plus de 10 ans on a eu un serveur Sun comme serveur NFS du labo, avec
des clients de toutes sorte, y compris Sun,HPUX, Linux et BSD, des serveurs X en
pagaille, etc. sans jamais aucun problème, y compris pour les locks.

Dis... Ton diplôme t'empêche-t-il de lire correctement ? Je ne parle

Tu attrapes la Stéphanite toi aussi! Un suffit amplement.
Je ne parle que de NFS, parceque franchement les problèmes de xdmcp
j'en ai rien à foutre.

Parfait, on va dire que moi aussi, je n'en ai strictement rien à
foutre de tes problèmes spécifiques de NFS et on sera avancés.

Comme je t'ai dit, on a eu jusqu'à une trentaine de
terminaux X qui sont partis depuis longtemps à la poubelle, donc le xdm
j'ai déjà donné, je ne veux plus en entendre parler. Heureusement les PC
indépendants sous Linux, ça résout ce problème, ça offre un affichage décent,
avec des fontes correctes et une vitesse raisonnable.

Ouaips, sauf lorsqu'une application à besoin d'un gros serveur Sun
tournant sous une certaines version de Solaris patchée de tous les
côtés. Dans ce cas, explique-moi comment tu vas faire avec des PC
sous Linux, que je rigole.

pas que du NFS (c'est une obsession chez toi, on dirait), mais de
tous les autres trucs qui font que plusieurs systèmes cohabitent
bien. Solaris avec Linux, c'est plutôt l'entente cordiale que
l'alliance à tout va. Je cherche toujours une solution pour attaquer
un poste Linux faisant du xdmcp à partir d'un poste Solaris 9 (et
j'ai blindé Solaris avec les fontes X de Linux, configuré les fontes
Solaris au travers de xfs tournant sur le poste Linux, demandé au
support de Sun... J'attends toujours la réponse !...)

Je ne comprends rien à ton problème. Pour avoir un bon affichage il faut des
fontes truetype de bonne qualité, comme les fontes Microsoft ou Bitstream Vera
et utiliser la librairie freetype2 avec le support du "hinting" qui se trouve
dans ces fontes. Il faut évidemment que tes programmes fassent appel à
freetype2 pour afficher les dites fontes. C'est le cas sous Linux, FreeBSD,
etc. sous Solaris je n'en sais absolument rien, mais si ce n'est pas le cas
rien n'empêche de recompiler entièrement xorg et les clients pour la machine.

C'est ça... Un xfs des familles _devrait_ résoudre les problèmes.

D'ailleurs il y a une distribution basée sur le noyau Solaris et l'userland
Gnome qui s'appelle Nexenta. J'avais essayé le cdrom live, c'était trés
chouette.Quand on tournait sous Sun on n'utilisait *jamais* ni le serveur X
ni les clients venant avec SunOS, tout était recompilé aux bons soins de
Pierre David. Et idem sous HP-UX.

Ouaips, et lorsqu'on a _besoin_ d'un Solaris _complet_, avec X parce
que l'appli à besoin d'un sombre module X, je fais comment ?

Je vais certainement dire une connerie, mais le support NFS est dans
le noyau. Si le noyau est patché par RedHat, tu changes le noyau
pour un officiel et on n'en parle plus. Maintenant, je maintiens

Oui le support est dans le noyau, et le responsable informatique ne veut pas
entendre parler de quoi que ce soit tel que changement de noyau ou tout autre
changement non standard. Il veut mettre le cdrom de Fedora et rien d'autre.
Quand on a 100 machines à tenir à jour, je ne peux pas lui donner tort.

Et bien s'il travaillait pour moi, il serait directement à la porte.
Lorsqu'on a un tel problème, on fait un noyau générique avec tous en
module et on propage le truc sur les serveurs pour toucher le moins
du monde aux clients. Mais c'est certainement une façon de faire de
dino avec des écailles. N'importe quel administrateur un tant soit
peu sérieux passe plus de temps sur les serveurs pour que cela
tourne que sur les postes clients.

Cataplasme sur une jambe de bois. Lorsqu'on corrige un truc, on
corrige la cause et non la conséquence. Je serais curieux de voir la
différence de conf, parce qu'il y en a forcément une.

En effet il y en a une, mutt -v affiche la configuration, et on voit
facilement qu'il n'y a pas de support de dotlock sous Fedora alors qu'il y est
sous Debian. Evidemment c'est le genre de chose qu'on remarque une fois qu'on
a trouvé la solution.

Mauvaise solution, changer solution. Mais c'est toi qui voit. Avec
une solution aussi bancale que cela, il y aura encore pas mal de
problèmes du même style.

Et regarder de près le fichier /etc/exports du serveur ? Et les
options de montages automatiques des clients (le cas échéant) ? Les
problèmes sont presque toujours là.

La mbox est bien rw, il n'y a aucun problème pour effacer le courrier avec un
autre programme que mutt, par exemple avec mail. C'est bien là que ça a
commencé à devenir intriguant. Il a fallu que je me tape de lire le code
source pour voir que mutt *déclare* la mbox ro s'il n'arrive pas à la
verrouiller avec flock() par exemple, mais surtout, ce que je n'ai pas vu tout
de suite, avec dotlock quand il est configuré dans mutt. (Evidemment elle
reste tout ce qu'il y a de plus rw, uniquement de façon interne il la
traîte comme ro, voir mx.c et dotlock.c dans le source).

Et alors ? Le rapport avec la choucroute ? Je parle de la
configuration de nfs et des options du noyau, pas de la
configuration d'un programme du style mutt qui est somme toute assez
bien configuré. La question est "pourquoi cette saleté n'accepte pas
les locks ?".

JKB

Michel Talon wrote:

Pour une fois je suis d'accord à 100%, d'ailleurs quand j'entends parler de
machines de calcul et de Windows dans la même phrase je me demande si on n'a
pas affaire à un fou furieux.

précision à mon post ...
les clients font le pre et post processing des calculs et les solveurs
sont sur les clusters ...

On Sat, 08 Apr 2006 09:51:03 +0200, Emmanuel Florac wrote:

Quant à la Fedora, je veux bien croire que la 4
est bien, mais la 1 et la 2 étaient pitoyables, à peu près aussi
lourdes qu'un XP patché et stables comme un win95R1.

Ah.... ben voilà! Pendant un moment je me suis dit que tu étais animé
d'une de ces mauvaises foi! :-)
Oui, la 4 est pas mal, et la 5 non plus (à premiere vue, reste a voir dans
le temps).

--
Debian/apt Repo: http://locataire-serveur.info/sections/liens/debian-repository
Fedora/yum Repo: http://locataire-serveur.info/sections/liens/fedora-core-yum

Michel Talon wrote:

Pour une fois je suis d'accord à 100%, d'ailleurs quand j'entends parler de
machines de calcul et de Windows dans la même phrase je me demande si on n'a
pas affaire à un fou furieux.

les ingés de Dassault Systèmes et Abaqus apprécieront :-)

http://www.abaqus.com/products/products_afc_v5.html
http://www.abaqus.com/support/v66/v66_platforms.html

Emmanuel Florac wrote:
(...)

Pour le poste de travail n'en parlons pas, un poste de travail qui ne
peut
ni lire un mp3 ni un windows media, ni afficher une page web avec du
flash, c'est proche de l'escroquerie.

yum install mplayer + codecs + install du plugin flash pour firefox ...
2 minutes montre en main ..

Hum hum! Sous réserve de jouer avec yum.repos.d pour ajouter les bons
dépôts, que ceux-ci fonctionnent comme il faut (p.ex. Livna ne répond
qu'une fois sur deux), que les dépendances soient correctement
satisfaites (genre mplayer a besoin d'une biblio plus récente mais
indisponible sur le dépôt), j'en passe et des pires. Ce qui fait qu'au
final on supprime ces dépôts tierce-partie pour éviter les ennuis.

arrête la mauvaise foi :-)

Paille, poutre, etc.

Je crois que Fedora *pourrait* être une distribrution très intéressante,
mais après 1 an et demi d'ennuis en tout genre (FC 3 et 4), j'ai laissé
tomber.

JKB <knatschke@koenigsberg.fr> wrote:

Et alors ? Le rapport avec la choucroute ? Je parle de la
configuration de nfs et des options du noyau, pas de la
configuration d'un programme du style mutt qui est somme toute assez
bien configuré. La question est "pourquoi cette saleté n'accepte pas
les locks ?".

Je t'ai dit qu'elle acceptait les locks (*). Le directory du mail n'est pas
read-write par tout le monde donc je suppose que mutt ne peut pas écrire
des fichiers du type user.machine.lock. Pourquoi ça marchait avant, c'est ce
que je ne sais pas, peut être qu'il y avait un programme externe mutt_dotlock
sgid à mail qui avait le droit de créér ces fichiers. Le pourquoi détaillé ne
m'intéresse pas, en ce qui me concerne je suis heureux avec la solution
consistant à recompiler mutt sur les clients qui en ont besoin, même si
ça cause du tracas - le tracas étant surtout pour les upgrades.

(*) précédemment les locks ne marchaient pas et il avait fallu que je recompile
mutt en renvoyant un succés systématique à flock(), encore une galère.

JKB

--

Michel TALON