ragoutoutou a écrit 1515 commentaires

OK, mais un peu de réflexion avant la parole ne fait pas de mal :-)

Oui, mais déjà une journée de perdue sur la validation de la plateforme à cause de ça... ça reste énervant... je trouve que mettre et up2date et yum dans rhes5 aurait été plus respectueux du client... Le client qui suit naïvement ce que RedHat offre et reprend est bon pour convertir tous ses scripts de déploiement.

Mouaif. Mouaif car tu fais quoi avec "yum --downloadonly" ?

Alimenter un workflow qui s'intègre dans les procédures de test et de validation pour alimenter une repository sur le lan.

Tu peux tout autant aller sur http://rhn.redhat.com/

opération manuelle, une opération automatisée est plus souhaitable pour notifier les paquets à faire valider et par qui, ainsi que de préparer les machines de test.

Puis c'est pas sorcier de mettre en place un firewall qui ne laisse passer que le protocol rhn en sortant.

Ce n'est pas une question de firewall, c'est le fait d'enregistrer des machines internes sur un site web à l'aide d'un client qui peut recevoir des ordres depuis ledit site web. Le firewall filtre les protocoles, pas les contenus ou la pertinence des informations retournées via un protocole licite. De plus, ça passe de toutes façons via un proxy, pas de connexions directes au web autorisées...

Certes. Mais as-tu contacté Red Hat avant de venir "gueuler" ici ? Si tu payes "plusieurs dizaines de millieurs d'euros" tu devrais faire ça en premier.

C'est en cours, mais je ne vais pas me priver de dire ce que je pense sur les forums pour autant...

Maintenant, c'est vrai que quand on n'a pas des masses de serveurs et pas toute une série de contraintes administratives et sécuritaires, la disparition du "download only" ne doit pas être une grosse perte.

En attendant, le plugin rhn pour yum est assez intéressant à lire et à modifier...

Si (PATROL== 'BMC Patrol')
alors affiche "condoléances" ...

Pourquoi tu veux les paquets binaires ? Pourquoi cette éxigence ?

- Parceque RedHat Network n'est pas adapté aux besoins de l'entreprise pour laquelle je travaille, que pour certains éléments il est carrément contraire aux polices de sécurité, et qu'il faut tout de même une méthode de distribution des hotfixes convenable quand on a un grand parc de serveurs avec des environnements différents ainsi qu'une compartimentation réseau.

- Parceque Rhel5 est une baisse de fonctionnalités à ce niveau par rapport à RedHat4.

- Parceque le contrat de support entre redhat et la société pour laquelle je bosse est de plusieurs dizaines de millieurs d'euros, et vu le prix unitaire de la license, ce serait sympa de traiter les clients un peu mieux.

Au fait, comment tu fais pour downloader un paquet MS ? Je n'ai pas trouvé.

Paquet, non, hotfix oui... et c'est facilement automatisable (si on ne veut pas utiliser WSUS, WUS, ... )

... très énervant, alors que sous rehat 4, il était encore possible de télécharger les mises à jour et packages sans les installer avec "up2date get", sous Redhat5, cette cochonnerie de yum est incapable de faire un --downloadonly (à moins que je n'ai raté une subtilité)

Tout ça pour forcer la main des clients pour qu'ils achètent Rnh satellite...

ben le vpn est le niveau de sécurité au dessus... le wifi peut même être non-crypté, un bon vpn sera de toutes façons en béton... Je faisais ça du temps où il n'y avait que le wep...

http://openvpn.net/howto.html

ça marche assez bien, j'ai un collègue qui avait implémenté une solution de remote acces au boulot avec...

En fait, AoE nécessite une connexion directe vu que ce sont des paquets ethernet non routables. Si tu as plusieurs vlans et que tu dois mettre un routeur entre ton serveur et ton san, AoE est hors de question.

iScsi, de son côté, permet de mettre des routeurs entre le san et le client.

En gros,

AoE bouffe moins de cpu

iSCSI est plus flexible

...

Et avec du hardware san iSCSI, l'os dialogue directement avec de vrais disques qui reçoivent les commandes scsi sans transformations.

bizzare... moi j'ai les iso "desktop" disponibles dans rhn...

Le nom du canal est "Red Hat Enterprise Linux Desktop (v. 5 for 32-bit x86)" (pour le version 32bit)

iSCSI, c'est le truc qui permet de rendre les SAN abordables, c'est ça ?

Oui, c'est un protocole transportant le scsi sur tcp/ip, donc contrairement à l'ATAOe, c'est implémentable avec une infrastructure réseau complexe.

Et ce truc ne marche pas aussi sur les autres distribs ?

Oui, mais ce n'est généralement pas intégré... il faut souvent recompiler...

tu lances quoi? comment? sous quelle identité?

A priori, c'est un problème de droits, tu es root quand tu lances le daemon? tu fais un sudo?

Par contre quand ça concerne l'économie, c'est justifiable.

Ben en tout cas, c'est une manière de faire des subventions déguisées...

Mais si tout le monde fait pareil, ça peut torpiller les échanges commerciaux et mettre en péril les industries...

cette lutte contre le patriotisme mal placé, c'est très français

Ben non, je suis belge...

Sinon, ce que je trouve ridicule, c'est de considérer qu'un Linux puisse être "bien français"... vu la quantité de code venant des quatre coins du globe... Faut arrêter ce délire.

Même Mandriva n'est pas vraiment une entreprise bien française vu sa composition franco-brésilio-étazunienne...

A part ça, je serais directeur de société de service, il est évident que j'essayerais de fourguer un produit sur lequel je peux faire une marge maximale plutôt que de devoir repayer des frais de licence sans avoir une amélioration flagrante de la qualité du produit...

De là à dire que Mandriva est à Linux ce que les diables Rouges sont au Foot...
... ce serait méchant tout de même.

D'un autre côté, au niveau institutions et grandes entreprises, un duel mandriva-ubuntu ressemble un peu à un match de seconde division...

Sinon, nous les belges, on fait quand même du vin assez minable, il faut le reconnaitre... on enterre la France pour la bière, mais la France nous enterre pour le vin... chacun son truc...

J'aurais également préféré qu'on retienne une solution bien française pour ça.

Si on retire tout le code qui n'est pas "bien français" de Mandriva, il ne reste pas grand-chose...

Il faut un peu arrêter avec ce patriotisme mal placé, Linux est un effort international, une mise en commun sans frontières.

D'abord ce n'est pas une distribution qui a été choisie mais bien une société de services, qui a répondu selon un appel d'offre. Spécifier dans l'appel d'offre que le produit à utiliser devait être mandriva aurait été contraire à la loi et à l'éthique.

Et si la société de services trouve son avantage à utiliser Ubuntu plutôt que Mandriva, à qui la faute?

Mandriva est une distribution commerciale, mais encore faut-il chez eux une volonté suffisante de vendre leurs produits.

ça dépend entièrement de la méthode de connexion... si c'est intégré au southbridge, ça ne doit pas poser de problèmes.

Si ça ne l'est pas, ça dépend entièrement de la méthode de connexion de la puce au southbridge...

Avec les cm récentes, ça devrait être du pci-express.

Sur des cartes mères serveur récentes, les interfaces intégrées à la cm sont toujours interfacés via pci-x ou pci express (le dernier étant de plus en plus plébiscité vu la réduction de complexité des cm qui en découle)

Il faudrait soit du gigabit intégré à la carte mère (via le chipset) soit du pci-X ou express...

Au niveau du processeur, pas de problèmes, les processeurs récents sont parfaitement capables de saturer une telle ligne assez aisément.

Le plus important, c'est la méthode de saturation...

sur un cd audio il y a des fichier .wav avec une bonne qualité de son et une bonne définition

Sur un cd audio, il y a des pistes PCM, pas des fichiers wav... D'ailleurs, sur un cd audio, il n'y a pas de système de fichiers (sauf si on joue avec des cd's mixtes, mais l'audio du cd audio reste hors de tout système de fichier)

D'ailleurs le wav est un format de container (comme avi, asf, mov, mpeg, ogm, ...) et pas un format de données. Il est tout à fait possible d'encapsuler du son autre qu'au format pcm dans un wav...

Pour Red Hat, ce serait plutôt...

[ ]Red Hat Linux WS Support Basic 30 jours (+143¤ ht)
[ ]Red Hat Linux WS Support Standard (+239¤ ht)

faut pas croire au père noël comme ça...

Je ne vois pas en quoi un pc devrait être vendu avec l'os préinstallé... La majorité des constructeurs le fait, mais ce n'est pas une obligation légale, au contraire, ça flirte avec l'illégalité de la vente liée.

Sinon, pour l'utilisation d'un stick usb, en général, ça marche bien pour les os récents basés sur linux.

Par contre, c'est impossible avec des windows standards.

La chose à éviter, c'est le swap sur la flash...

Quand est-il réèllement ?

Réellement? J'utilise des cartes mères msi depuis 10 ans, et aucune déception à l'heure actuelle... ce qui n'est pas le cas d'autres marques pourtant plus réputées.

... en tout cas ça fait un bout de temps qu'à la fnac, les linux disparaissent.... faut dire que c'est pas génial linux, dans un magasin... il y a x versions qui sortent sur une année, donc du stock qui fini vite comme invendu, ... alors que windows, le produit reste d'actu quelques années, moins risqué donc.

Et de bonnes distributions gratuites sont dispo sur le web ...

Et puis les utilisateurs confirmés, ils n'achètent pas à la fnac...

En passant, ça n'a rien à voir avec le fil EFI... mais avec les origines de cette "news" à deux balles...

Cela dit, c'est déjà une avancée d'avoir un linuxBios vendu de base sur une cartemère

Pour dire simplement: non, ce n'est pas une avancée puisqu'il n'y en a pas... la dépèche est de l'intox, il n'y a aucune source valide, et il est dommage et peu pertinent de continuer à parler comme si une telle carte était vendue...

Ok, on motive pas, môssieur fait un caca nerveux...

Ok, on se donne la peine de motiver, môssieur fait un caca nerveux...

Jamais content...