mururoa69 a écrit 287 commentaires

Pour windows aucune idée.
Pour les Unix propriétaires on peut facilement récupérer les mises à jour et ces mises à jour se présentent sous la forme de "service pack" qui intègrent les mises à jour de sécurité. Par exemple sous Tru64 il y a des patchs kits et ensuite on peut lister toutes les mises à jour qui sont sorties après un patch kit, choisir celles qui nous intéressent et les télécharger puis les installer aussi facilement sur les machines que l'on veut patcher.
Pour debian encore plus facile, il suffit de faire en local une copie du dépôt debian-security.
On ne peut pas, pour des raisons x,y et z, essentiellement les mêmes que celles de ragoutoudou a exposées, enregistrer tous les serveurs ( 200+ ) sur rhn, ni permettre à redhat de voir ou d'agir sur nos serveurs ni se permettre d'appliquer des niveaux de patchs differents en fonction de la date de mise à jour, ni ...
Idem pour l'utilisation du satellite.
Il faut comprendre que redhat déconnecte volontairement les mises à jour et les patch de sécurité pour des raisons essentiellement commerciales.

Ouais c'est pas simple on dirait.
C'est rageant quand on connaît la facilité d'avoir un dépôt security avec une debian ...

Aucun rapport ils cherchent juste un développeur prêt à mouiller sa chemise pour eux. Genre on a une idée mais pas les compétences alors si vous avez les compétences on est prêt à partager, un peu, le pognon.
Un extrait du site : "Nous avons un coeur énorme, de grandes ambitions et nous sommes prêt à tout faire pour arriver à nos fins."
Damn, surtout ne pas dépénaliser le droit des affaires; ils sont prêt à tout !

Déjà le kernel est inclu dans le domU avec pygrub. Ensuite même si ça peut marcher, les modules par exemple sont compilés pour une version particuliere de kernel. Les options et fonctionnalités des kernels sont différentes. Maintenant tu peux utiliser le même kernel sur plusieurs distribs en le compilant mais là tu t'eloignes du standard de la distrib. C'est une piste qui est interessante pour la mobilité des domU en dehors de pygrub mais qui n'a plus trop de sens avec pygrub.
A mon sens il faut un grub-install. Je ne comprends pas trop ton /dev/xdva#. Tu presentes un disque au kernel sur lequel tu as installé ton OS et pas une partition. Et oui il faut bien une table de partition même si il n'y a qu'une partition primaire qui prend tout le disque.

Oui j'ai des dom0 en debian et d'autres en redhat.
J'essaye d'utiliser pygrub parce que ça permet de tout mettre dans le domU et donc de bouger beaucoup plus facilement les domU d'un serveur à un autre. Idealement mes domU devraient pouvoir tourner indifferemment sur debian ou redhat.
Par contre ça ne va pas le faire de booter un domU redhat avec le kernel de la debian ;)

Ubuntu le fait donc debian peut le faire aussi.
Il se trouve que dans mon cas c'est pertinent de tout installer par kickstart.

J'ai essayé iozone déjà. Un peu trop chiadé pour mon besoin mais surtout les résultats sont incohérents.
Par exemple dans la plupart des tests de read j'arrivais à lire plus de données que le débit de théorique de l'interface SAN. Ca montait à 465 Mb/s avec une moyenne vers 220 MB/s alors que je n'ai qu'un seul brun SAN à 200 MB/s. Donc j'ai un tres GROS doute sur l'utilité d'un bench qui te donne des résultats tout simplement impossible.
Bonnie est beaucoup moins eye candy mais finalement c'est le plus cohérent de ce que j'ai essayé jusque là.

hdparm est interessant mais il ne donne qu'un indice en lecture avec et sans cache. Un peu insuffisant.
L'autre m'a l'air pas adapté au besoin.

hdparm est interessant mais il ne donne qu'un indice en lecture avec et sans cache. Un peu insuffisant.
L'autre m'a l'air pas adapté au besoin.

Heu ben ok, je vais essayer de comprendre tout ça et de voir si ça marche.

1/ Ca date de 2003 et ca a forcement déjà été fait par d'autres sans réponse (cf les sites ou les gars pointent le driver ).
2/ Poster sur un site linux pour trouver un driver qui permet de communiquer avec un PDA sous linux me parait tout à fait approprié. Ce driver existe mais est introuvable et si quelqu'un l'utilise encore c'est possible qu'il frequente ce site.
2b/ Les utilisateurs de yopy aussi sont suceptibles de frequenter ce site et le driver yopy pourrait aussi m'être utile.
3/ Je ne vois pas trop ce que tu appelles "profil USB" mais concernant linux il y a des howtos qui expliquent de long en large comment communiquer avec le PDA. En gros c'est du TCP over USB et c'est pas transposable sous windows sans driver. Il faut creer sous windows une pseudo carte réseau pour communiquer avec le PDA avec une adresse IP. A la connexion windows voit un "ethernet gadget" et n'a aucun driver pour ça.
3a/ Pas à ma connaissance non, c'est pas un zaurus, mais si tu en as entendu parler ...

C'est un peu etonnant que personne ici n'aît eu le même problème.

Heu, t'as pas tout lu sur le lien que tu donnes. C'est bien le driver d'origine qui "cease to work by the 31 october 2003". Ce que je cherche c'est pas le driver d'origine mais la version hacké qui n'a pas de limitation ou tout autre moyen de communiquer par le port USB avec un windows.
Et non le 1915 n'a pas de port série par défaut. Il y a peut-être un adaptateur mais je te laisse imaginer la vitesse de transmission ;)

J'ai demandé à Corsair.
Si qq peut répondre c'est bien un fabriquant de clé.

Bah c'est pas tres encourageant tout ça :(
Le mieux c'est encore de trouver une clé avec le petit bouton physique qui la protege en ecriture on dirait.
Si quelqu'un utilise un utilitaire windows ou linux pour gerer sa clé pour acceder par exemple à des partitions chiff'rees peut-être que l'utilitaire permet aussi de proteger la clé ?
Ce qui me gene c'est qu'il y a pas mal de travail pour faire cette clé alors si un utilisateur arrache la clé un peu brutalement d'un ordi sans synchro le risque c'est de se retrouver avec une clé bouzillée. Juste par exemple si un utilisateur veux voir ce que la clé à dans le ventre il la plug sur son windows, ne vois rien et l'arrache :(

Oui ça doit doit forcement être independant de l'os.
On doit bien pouvoir le faire; enfin j'espere.
Ca doit bien être stocké qq part sur la clé le statut du writeprotect et donc ça doit bien être modifiable.
C'est une clé d'installation redhat 5 que j'ai fait et j'ai pas trop envie qu'une fausse manip me fasse perdre des données sur la clé d'autant que c'est déjà arrivé.

Donc je precise mon besoin : je veux forcer le write protect sur la clé pour que quand je la mette dans n'importe quel ordinateur le message soit :
sda : Write Protect is on
et pas :
sda : Write Protect is off
Comme si j'avais le petit bouton de write protect qui est present sur certaines clés.

Heu ça je sais faire. C'est pas le problème.
J'ai quand même rtfm et gimf avant de poster ;)
Le probleme c'est que je ne la monte pas moi même la clé mais que je perd des données / structures dessus après l'avoir utilisée sans la monter directement au cours d'un processus d'installation de linux.
En gros elle est correcte. Je fais 2 installs avec et là j'ai perdu des infos de structure donc elle ne fonctionne plus.

Oui c'est ça.
Ca devrait être dans le man !
Merci.

Franchement ça m'etonnerais parce que si Oracle viens gratter RH sur son terrain et ne propose pas un support de qualité alors personne ne va utiliser leur produit mais plutot continuer à installer la database sur une RHEL.

Si tu respectes les conditions d'utilisation de la distribution tu peux tout à fait faire appel au support.
Sinon c'est du piratage, comme si tu installais des windows 2003 server sans licence.
Si tu t'imagines que linux c'est le monde du tout gratuit tu te fourres le doigt dans l'oeil jusqu'au coude.

Je plussois.
Il y a maintenant pas mal de petits routeur/switch vraiment pas chers qui peuvent se configurer facilement avec un simple navigateur ou un assistant que c'est vraiment dommage d'avoir à allumer une machine A pour permettre à une machine B d'avoir acces à internet.
Dans les 30 ¤ on trouve des routeurs avec 4 ports switch et un port pour les relier à un modem ou une box.
Si on met un peu plus on peut même avoir des routeurs/switch qui permettent de partager des imprimantes et des disques sur le reseau.

Pouh la la ... c'est pas simple !
J'ai trouvé une info moyennement satisfaisante : http://wiki.xensource.com/xenwiki/HVM_Compatible_Motherboard(...)
Donc ça passerait avec win2k et win2k3 mais pas XP et probablement linux et d'autres OS.
Enfin ça veut dire que le support de AMD-V est bien là en tout cas et on peu esperer que ça s'améliore avec les versions successives de bios.
Par contre c'est une des 3 seules CM listées donc j'ai eu le nez creu sur ce coup-là.
Apres il n'y a pas que xen comme virtualisation donc je vais partir sur celle-là et voir ce que je peux faire.

Oui c'est ça M2NPV-VM ( Virtual Machine ? )
J'ai vu la liste des procs supportés et tous les X2 et les opterons ont bien le support de pacifica. Le hic reste toujours de savoir si c'est exploitable sur cette carte mère alors qu'il n'y a rien dans le bios.
C'est quand même fort de la part d'AMD de ne pas indiquer les chipsets/cartes mères compatibles. Ou alors il suffit que le CPU le supporte et c'est automatiquement supporté par la CM mais alors j'aimerais bien trouver l'info qq part.
Personne fait de la virtualisation hardware avec un AMD ???

Non j'ai pas la CM. J'essaye de faire le truc dans le bon sens et de verifier avant ;)
Je penche pour une Asus N2NPV-VM mais je n'ai rien vu dans le manuel de la carte ni sur le site Asus. J'ai envoyé une demande à Asus.
Par contre si quelqu'un lit ce message et qu'il a un Athlon X2 sur socket AM2 j'aimerais qu'il execute le dernier CPU-Z sur sa becane parce que cet utilitaire donne l'nformation concernant le support de la virtualisation ( Secure Virtual Machine Extensions / pacifica ). Au moins pour le CPU.

C'est bien ça le hic la gestion ou non par la carte mère et/ou le chipset.
Et c'est bien l'info que je cherche : savoir qui qq a réussit à faire tourner correctement xen en virtualisation hard et si oui sur quelle CM.
Chez AMD ça s'appelle pacifica et c'est présent sur tous les X2 sur socket AM2 ( pas les sempron et pas les X2 sur socket 939 ) donc ce point est clair pour moi.
Pour le superviseur xen il y a linux ou netBSD et en principe je vais prendre netBSD parce que c'est plus efficace et que de toute façon le dom0 ne va faire que gerer les differents domU.