Cher journal,
Je t'écris pour la première fois, pour t'annoncer un petite nouvelle dans le monde de la virtualisation:
Quelques jours après celle de VirtualBox 1.6.6, la version 2.0 est disponible (depuis hier en fait), avec enfin un support des guest 64bits (avec un hôte 64bits), une meilleure intégration à Mac OS X, passage en Qt4 de la GUI et pas mal de petites autres choses.
Le changelog : http://www.virtualbox.org/wiki/Changelog
Pour rappel, Innotek (qui développe VirtualBox) à été racheté par SUN début 2008. Il existe 2 versions, dont une sous licence GPL.
Perso j'utilise VirtualBox pour virtualiser un Windows XP (oui, ca peut servir pour des tests !), et ca tourne nickel (le mode seamless, permettant d'integrer les applis guest sur l'hote est très utile ! -voir par exemple http://www.korben.info/virtualbox-15-et-la-virtualisation-se(...) pour plus d'infos).
Les OS supportés : http://www.virtualbox.org/wiki/Guest_OSes (pas forcement très à jour je pense).
# VirtualBox closed-source Features
Posté par a_jr . Évalué à 9.
Mais des qu'on veut aller un peu plus loin...
- lancement d'un OS invite en tache de fond : impossible car l'interface graphique via RDP est proprietaire
- acces aux peripheriques USB : proprietaire
- support un peu complexe des disques : proprietaire (iSCSI ou SATA)
C'est ecrit la : http://www.virtualbox.org/wiki/Editions, en bas.
Sun aime le libre, mais a quand meme mis plus de 10 ans a liberer java !
Rien a voir : Redhat vient d'acheter Qumranet, la societe qui bosse sur KVM.
Le bonjour chez vous,
Yves
[^] # Re: VirtualBox closed-source Features
Posté par imr . Évalué à 2.
Sur la FAQ http://www.virtualbox.org/wiki/User_FAQ je vois des références au support USB.
[^] # Re: VirtualBox closed-source Features
Posté par FabienC . Évalué à 5.
http://www.virtualbox.org/wiki/Editions
[^] # Re: VirtualBox closed-source Features
Posté par imr . Évalué à 1.
[^] # Re: VirtualBox closed-source Features
Posté par Fabien Engels . Évalué à 10.
non ?
[^] # Re: VirtualBox closed-source Features
Posté par ʭ ☯ . Évalué à 6.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: VirtualBox closed-source Features
Posté par libre Cuauhtémoc . Évalué à 3.
[^] # Re: VirtualBox closed-source Features
Posté par NeoX . Évalué à 5.
tu verras ca fait comme virtualbox, mais avec kvm/qemu/xen
[^] # Re: VirtualBox closed-source Features
Posté par Mildred (site web personnel) . Évalué à 8.
- redimensionner la fenêtre à loisir
- que la souris passe de l'hôte à l'invité de manière transparente
- le mode seamless
Je ne sais pas si ces drivers sont libres (honte à moi) mais il sont par contre très pratiques. C'est ce genre de choses qui permet à un utilisateur standard d'utiliser quelque chose comme qemu ou pas.
[^] # Re: VirtualBox closed-source Features
Posté par libre Cuauhtémoc . Évalué à 1.
[^] # Re: VirtualBox closed-source Features
Posté par libre Cuauhtémoc . Évalué à 7.
Il y a toujours eu deux versions de VirtualBox.
au commencement, VirtualBox était propriétaire, et l'éditeur de l'époque a libéré une partie du code et la sortir en GPL.
Bref même top oque StarOffice/OpenOffice:
tu as VirtualBox OSE et VirtualBox
Enfin, pour finir, mes amitiés à Anabella.
# Réouverture des dêpots officels deb
Posté par baptiste1ch . Évalué à 6.
Heureusement, les dépôts deb de Virtualbox sont dorénavant accessibles et mis à jour.
# pas de 3D
Posté par ndesmoul . Évalué à 3.
Évidemment, autant le support de l'accélération OpenGL est "relativement" aisé à intégrer (il y a déjà des travaux sur lesquels se baser comme VMGL, http://www.cs.toronto.edu/~andreslc/xen-gl/ ), autant le support de DirectX risque d'être plus chaud, même si un tel driver devrait pouvoir se baser sur Wine.
Ça serait déjà sympa qu'ils intégrent l'accélération OpenGL, au moins sous un Linux virtualisé. Ça permettrait de tester des distribs avec les effets graphiques activés. J'ai cru comprendre qu'ils avaient commencé à intégrer cela mais que cela n'était pas très stable et désactivé par défaut.
[^] # Re: pas de 3D
Posté par Snarky . Évalué à 4.
[^] # Re: pas de 3D
Posté par ndesmoul . Évalué à 4.
Surtout que la concurrence commence à le faire (VMWare mais pas seulement). Du coup ça serait dommage que VirtualBox, qui est par ailleurs un très bon logiciel que pour mon usage je préfère largement à VMWare (et pas uniquement parce qu'il est libre), prenne trop de retard sur ce sujet par rapport à la concurrence.
On peut donc espérer voir arriver un jour un tel support.
Ça pourrait même être déjà le cas pour OpenGL sous Linux (que VMWare ne supporte d'ailleurs pas sauf via VMGL).
[^] # Re: pas de 3D
Posté par loufoque . Évalué à 4.
Ce qui peut se faire avec le VT-d d'Intel, par exemple.
# VirtualBox me sauve la vie
Posté par Loic Dreux . Évalué à 6.
[^] # Re: VirtualBox me sauve la vie
Posté par B16F4RV4RD1N . Évalué à 4.
VirtualBox est vraiment très pratique, léger et simple à mettre en place (beaucoup plus que Vmware)
Cela me sert beaucoup pour tester d'autres distributions et des OS plus exotiques...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: VirtualBox me sauve la vie
Posté par bob le homard . Évalué à 5.
euh rien a voir avec le sujet... mais t'as pas une interface web (en java) pour gérer ton pabx?
Parce que pour le coup oui effectivement, c'est ennuyeux.
[^] # Re: VirtualBox me sauve la vie
Posté par B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: VirtualBox me sauve la vie
Posté par porki . Évalué à 1.
[^] # Re: VirtualBox me sauve la vie
Posté par porki . Évalué à 1.
[^] # Re: VirtualBox me sauve la vie
Posté par Benoît Bâlon (site web personnel) . Évalué à 3.
Comment ? un linuxien qui n'aime pas la ligne de commande ? ;) Par défaut, les OmniPCX sont accessibles via Telnet, je crois...
Pour ce qui est de l'OmniVista 4760 (outil de supervision), la partie serveur est en C++ avec un SGBD Sybase, et ne s'installe que sur du Microsoft. La partie cliente est développée en Java, donc devrait pouvoir tourner sur n'importe quelle machine, malheureusement ils ne fournissent un installeur que pour Windows... Mais il y a peut-être une interface Web également, à vérifier.
Pour info, la précédente génération de PABX Alcatel tournait sur du Windows NT, tandis que la génération actuelle tourne sur la base d'une Mandrake (ça remonte déjà à quelques années, en effet) avec un kernel patché. Je ne suis pas sûr qu'ils respectent la GPL, d'ailleurs...
[^] # Re: VirtualBox me sauve la vie
Posté par porki . Évalué à 1.
Là où je travaille nous avons effectivement des OXE qui utilisent Mandrake (7.2 de mémoire). Cependant j'ai lu sur le net que les derniers OXE utilisent Red Hat.
Je pense qu'ils ne sont pas très propres vis-à-vis de la GPL. J'avais posté un journal sur le sujet : je n'ai pas réussi à avoir le code source, mais je ne sais pas si cela a bloqué côté Alcatel ou dans l'entreprise où je travaille.
# Un peu pénible
Posté par jerome (site web personnel) . Évalué à 1.
Bon, avec KVM, c'est nickel, mais j'apprécie l'idée de virtualbox et de son relative portabilité histoire de faire tourner mes instances à d'autres personnes sous mac ou windows. Pratique. Du coup, ce matin, j'installe vbox 2.0 sur une debian. Je monte un guest debian dedans :
- pas d'interface, mais une (en fait 3) lignes de commande, voire une édition de fichier XML pour placer les redirections
- bug au chargement du kernel (sans trace dans les logs)
- si pas de bug (aléatoirement), pas de port forwarding, même si tout a l'air OK
Un peu pénible.
/me grognon.
[^] # Re: Un peu pénible
Posté par Aefron . Évalué à 4.
... maintenant, la pérennité des images...
Virtualbox-OSE, je l'ai laissé tombé après deux fois où, à une mise à jour, il m'a sorti que le format d'image avait changé, et que le nouveau n'était plus compatible avec l'ancien...
... du coup, depuis, c'est qemu+qemulator+kqemu/kvm (selon ce dont la machine est capable)... et depuis, pas de souci.
[^] # Re: Un peu pénible
Posté par NickNolte . Évalué à 2.
qemu...qemulator...kqemu/kvm là ou une seule occurence VirtualBox™ suffit!
Je sais que qemu est le "backend" mais quand tu balances tout ça de cette façon, ben on a l'arrière goût "linux-bordélique" qui remonte.
[^] # Re: Un peu pénible
Posté par Aefron . Évalué à 3.
Sans compter les virtualbox-ose-guest-utils, pour faire du partage entre hôte et invité, là où le partage de partoche, voire le montage d'une clé USB se fait sans problème avec qemu tout seul...
[^] # Re: Un peu pénible
Posté par Ririsoft . Évalué à 2.
De mon experience propre l'USB est supporté mais seulement en USB 1 qui est très très lent. D'autres part je ne peux pas utiliser certains appareils qui ne veulent entendre parler que d'USB2 (comme les nouveaux iPod).
Je n'ai pas non plus la chance d'avoir un CPU kvm donc j'en suis réduit à kqemu.
qemu + kqemu est vraiment plus lent que virtualbox.
J'aimerais tellement remplacer Vbox par qemu ... Vous aussi vous avez cette déception ?
[^] # Re: Un peu pénible
Posté par herodiade . Évalué à 4.
[^] # Re: Un peu pénible
Posté par Ririsoft . Évalué à 1.
Tu voulais dire EHCI ? Tu as trouvé cette info où, sur la ML ? J'aimerai bien aller voir où ils en sont ...
[^] # Re: Un peu pénible
Posté par herodiade . Évalué à 2.
Les patchs offrant le support EHCI vient d'être proposés.
> Tu as trouvé cette info où, sur la ML ? J'aimerai bien aller voir où ils en sont ...
Sur la mailing-list de qemu : cherche les mails envoyés par Max Krasnyansky en août et septembre.
[^] # Re: Un peu pénible
Posté par Ririsoft . Évalué à 1.
[^] # Re: Un peu pénible
Posté par Aefron . Évalué à 1.
Il y a aussi que, par défaut, qemu n'alloue que 128MB de RAM à la machine virtuelle, là où, par défaut également, virtualbox en alloue 256MB... et ça change tout...
... en passant qemu à 256MB de RAM pour la VM, en ayant comparé l'install de Debian customisée via simple-cdd sur un pentium-m 1,7GHz (donc, sans accélération matérielle), la différence entre les deux, elle est bien moindre.
[^] # Re: Un peu pénible
Posté par Kerro . Évalué à 5.
J'aimerais tellement remplacer Vbox par qemu
Pour ma part j'aimerais remplacer vmware par qemu ou KVM en environnement de production. Nous avons actuellement une quarantaine de machines virtuelles, rien que du Windows. Avec vmware ça fonctionne presque très bien. Les performances sont excellentes (meilleures qu'avec Windows bare metal, sauf en calcul pur mais nous n'en faisons pas), la stabilité, rien à redire. Le seul point négatif c'est que la configuration de vmware est mal faite, mal documentée pour les paramètres pointus, et que des choses basiques remettent en place les paramètres par défaut (c'est probablement leur manière d'éviter que certains incompétents se plaignent).
Pourquoi qemu ou KVM alors que vmware fonctionne très bien (et gratuitement) ? Par préférence "libertaire". Et je pense que c'est également plus facile à gérer via des outils maison.
[^] # Re: Un peu pénible
Posté par NeoX . Évalué à 2.
il y a une seule condition à ma connaissance, le disk vmware doit etre en un seul morceau pour pouvoir etre convertit en disque pour qemu/kvm
ensuite j'avais trouvé sur internet (mais pas testé) une commande pour convertir la VM en Kvm
[^] # Re: Un peu pénible
Posté par Kerro . Évalué à 2.
[^] # Re: Un peu pénible
Posté par NeoX . Évalué à 3.
mon equipe de QA commence à passer sous KVM car sous VMware on constate des decalages d'horloges (ennuyeux pour du monitoring ou de la synchro de serveur)
j'envisage moi meme de passer mes serveurs emails sous kvm
[^] # Re: Un peu pénible
Posté par frafra . Évalué à 2.
Dis à tes admins de fouiller sur google ou sur le site vmware, il faut juste modifier un param du kernel et au pire installer ntp.
Un lien parmi d'autres : http://kb.vmware.com/selfservice/microsites/search.do?langua(...)
[^] # Re: Un peu pénible
Posté par NeoX . Évalué à 3.
pas vraiment le temps de me pencher sur les 50 vm sous gentoo
alors que nos services migrent un par un sous ubuntu.
j'ai bien trouvé une astuce qui consiste à installer les tools dans le guest, puis à activer une variable à true dans le fichier de config de la VM.
mais :
1°) les tools sur une gentoo de 2007-08, ca le fait pas sans modifier tout le systeme
2°) meme avec des ubuntu ca marche pas toujours.
3°) recompiler le kernel d'un serveur qui heberge 20 machines virtuelles, vaut vraiment pas se louper
je ferais un essaie avec ton lien qui est plus precis que ceux que j'avais trouvés precedemment.
et sinon, KVM c'est libre quand VMware Server est juste gratuit...
ce qui en soit est deja mieux pour ma boite.
[^] # Re: Un peu pénible
Posté par frafra . Évalué à 2.
Moins coûteux qu'une migration si tu as déjà les licences vmware.
Mais comme tu le dis ... c'est toi l'admin :)
# eaux troubles
Posté par Chapellon Alexandre . Évalué à -1.
J'ai jamais réussi à trouver d'intéret à virtualbox...
D'un point de vue philosophique: la position d'Innotek (ou Sun maintenant) n'a jamais été très claire vis à vis du libre... en règle général je n'aime pas ce modèle économique qui consiste à libérer du code qui a déjà son équivalent, et à conserver les fonctionalités intérressantes planquées derrière des licences propriétaires...
D'un point de vue technique: je trouve les interfaces graphiques USELESS dans le cadre de la virtualisation à petite échelle: les scripts sont tellement plus souples et performants! Quand tu dois déployer des dizaines et des dizaines de machines virtuelles, gérer des migrations de hosts ou faire du cloud computing... c'est une autre histoire.
D'un point de vue des perfs: bah que dire? ca vaut un qemu+kqemu à peu près....
On est loin des performances que l'on peu atteindre avec un xen ou un esx (vous remarquerez le double lancement de troll!)
[^] # Re: eaux troubles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0.
Alors là, pour le coup, je ne peux que plussoyer. Pour pouvoir simplement tester une installation de système d'exploitation et des captures d'écran, j'ai essayé plusieurs logiciels de virtualisation. Qemu m'a bien plu, Bochs m'a semblé une bonne usine à gaz, et VirtualBox un affreux cliquodrome. Bref, depuis, c'est Qemu ou KVM, qui sont simples à utiliser, au moins.
[^] # Re: eaux troubles
Posté par Yth (Mastodon) . Évalué à 4.
C'est pour lire les DVDs des archives du new yorker, il y a un logiciel fermé qui tourne sous windows pour les lire. Il ne tourne pas avec wine, donc utilisation de qemu avec un vieux windows de derrière les fagots, et là rien à faire il ne reconnaît pas le DVD, il demande de l'insérer dans le lecteur, qu'il soit en ISO et émulé, ou en réel directement via le périphérique.
J'ai essayé avec virtualbox, et c'est pareil, sauf qu'il y a une option « Activer le mode direct », qui sauve la situation !
Je ne sais pas exactement ce qui se planque derrière tout ça, probablement une sécurité bien crade, mais j'aimerai bien savoir comment régler ça sous qemu...
Yth.
[^] # Re: eaux troubles
Posté par NickNolte . Évalué à 10.
D'un point de vue technique: je trouve les interfaces graphiques USELESS dans le cadre de la virtualisation à petite échelle
D'un point de vue linguistique: qu'est-ce qui t'empêchait de dire INUTILES ici???
INUTILES, FUTILES, SUPERFLUES, VAINES, SANS INTÉRÊT, DISPENSABLES,... et j'en passe certainement.
[^] # Re: eaux troubles
Posté par BAud (site web personnel) . Évalué à 3.
http://fr.wiktionary.org/wiki/superf%C3%A9tatoire
[^] # Re: eaux troubles
Posté par rictus (site web personnel) . Évalué à 3.
J'étais un utilisateur de qemu+kqemu, et ça répondait bien à mon besoin, mais les perfs étaient assez moyennes sur ma machine (T5500 2 Go Ram pourtant)...
Du coup, j'ai testé virtualbox, et j'ai constaté des perfs très supérieures...
Mon cpu n'a hélas pas les extensions VT pour pouvoir tester kvm...
Sinon, l'interface graphique de virtualbox n'a rien de "génante", moi je la démarre via un script "de démarrage" dans un vnc. Et on peut tout controler (démarrage/arrêt d'une vm, montage d'un cdrom, ajout d'un disque) via la commande vboxmanage.
Une dernière remarque : les scripts pour créer les interfaces réseaux virtuelles et les relier à un bridge me semblent plus simples et mieux foutus que ce qu'il y avait pour qemu il y a environ 2 ans (ce qui a peut-être changé maintenant).
Bref, plutôt que troller, je trouve très bien qu'il y ait plusieurs bonnes solutions de virtualisation libres...
# Question pas si innocente
Posté par jice (site web personnel) . Évalué à 1.
Pour ma part je ne le fais pas, car sur ma machine ne tourne presque que du logiciel libre, et y faire tourner Windows me débecte, mais je comprends surtout l'utilisation en milieu professionel (cf message sur le pabx ci-dessus).
[^] # Re: Question pas si innocente
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: Question pas si innocente
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Question pas si innocente
Posté par jice (site web personnel) . Évalué à 3.
sinon oui, c'est le sens de ma question. les seules fois ou j'ai vu un windows tournant dans une machine virtuelle sous linux (je parle hors du monde professionnel, où en général on paie les logiciels payants qu'on utilise), c'était une "copie". Cela choque le défenseur du logiciel libre que je suis, et qui serine autour de moi : "tu veux un logiciel payant ? tu le paies. Ou alors tu prends l'équivalent libre."
je voulais connaître votre position sur cette question ; désolé si elle n'était pas très claire ;-)
et oui, je sais, il y a des périphériques qui ne fonctionnent que sous windows, mais je vais au bout de mon raisonnement, et il y en a 2 qu'on m'a offert et qui prennent la poussière chez moi. sinon y'a de très bonnes bases de données de matériel qui fonctionne sous Linux, à utiliser avant tout achat (l'excellent http://hardware4linux.info pour n'en citer qu'un).
Quant aux jeux, je ne joue qu'aux jeux libres. oui je sais, c'est un peu ayatollah comme position ;-)
[^] # Re: Question pas si innocente
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: Question pas si innocente
Posté par Putifuto . Évalué à 2.
libre ne veut pas dire gratuit.
[^] # Re: Question pas si innocente
Posté par Ph Husson (site web personnel) . Évalué à 1.
[^] # Re: Question pas si innocente
Posté par APDT . Évalué à 5.
En fait, c'est la vente liée qui m'empêche de sombrer dans la délinquance !
# virt-manager
Posté par IsNotGood . Évalué à 8.
virt-manager a été initialement developpé par Red Hat. Ubuntu l'utilise (et Novell/SuSE aussi ?).
C'est ultra simple d'utilisation. Ça peut-être cliquodrome, ou en "shell". Virt-manager utilise libvirt (qui gère Xen, KVM/qemu, etc).
C'est aussi intégré à Policy-kit, donc pas besoin d'être super-utilisateur.
Bref, que du bonheur (même s'il reste quelques bugs).
Virt-manger :
http://www.virt-manager.org/
Libvirt :
http://www.libvirt.org/
C'est que du libre, pas de modules proprios, etc.
En passant, ovirt :
http://www.ovirt.org/
[^] # Re: virt-manager
Posté par Olivier Grisel (site web personnel) . Évalué à 1.
[^] # Re: virt-manager
Posté par Chapellon Alexandre . Évalué à 2.
Ainsi des projets qui l'utilisent (comme l'excellent enomalism) peuvent/pourraient manager différentes techno de virtualisation... vive la standardisation!
[^] # Re: virt-manager
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Moi, je veux des fichiers de conf fait pour les humains comme ceux de Xen à la base. D'ailleurs, Xen les transforme ensuite à un format parent du XML puisqu'ils sont en un dialecte du LISP.
Bref, virt c'est bien mais SVP, pas de XML sous /etc.
[^] # Re: virt-manager
Posté par benja . Évalué à -4.
Sinon, comme dit plus haut, un des grands intérêts de virt-manager, c'est la libvirt, ses bindings (python,perl,ruby & ocaml (-: ) et ses outils CLI associers. C'est une très bonne idée d'essayer de fédérer l'usage et l'administration de machines virtuelles autour d'une API unique. Et cela, ce n'est clairement pas orienté clickodrome, même si cela favorise l'émergence de GUIs sophistiquées et inter-opérables ;-)
[^] # Re: virt-manager
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Les fichiers de configuration sous UNIX sont depuis des années loin d'être en XML et UNIX est loin de ne pas être orienté entreprise !
Les fichiers de conf en XML proviennent de toute la tringlerie insupportable du java avec Tomcat et autres. On sais très bien faire des fichiers de conf lisible par l'homme et par la machine, par exemple le YAML. Pour information, l'ensemble de la cohérence des milliers de module (classe pour la plupart) du CPAN de Perl sont pilotés par de simple fichier YAML. Tu ne va pas me dire que la gestion des tes machines virtuelles est un problème plus complexe et doit être plus professionelle que celui du CPAN !
Faire cela sous XML, c'est effectivement pour simplifier les outils de plus haut niveau qui manipule alors ce genre de fichier facilement avec l'aide des bibliothèques toute faites pour le XML. Enfin, pour la quantité et le type d'information que l'on y retrouve, on fait tout aussi bien en YAML...
Ecrire un générateur, cela revient en pratique à lire et à écrire dans un fichier une structure d'arbre. C'est assez facile, pas besoin encore de se focaliser sur le XML.
Bref, sous des arguments que je considère comme fallacieux : "il me faut des méta outils qui puisse me générer mes fichiers de conf", on va finir par se retrouver avec un /etc imbittable et être obliger d'avoir des clickodromes pour gérer ses machines Linux (voir une base de registre !).
Je gère mes serveurs sans X-Windows, j'ai des dizaines de machines virtuelles et le tout est cohérent avec le tout génial cfengine qui n'a pas une ligne de ce truc imbittable pour l'homme qu'est le XML.
Désolé, je n'ai pas envie de gérer mes serveurs Linux comme des serveurs Windows... Et je vois de plus en plus de personne venant installer des prologiciels sous Linux qui viennent du monde Windows et qui amènent et appliquent les mauvaises méthodes de Windows sous Linux.
Un programme de type service système ne devrait pas avoir une application graphique comme dépendances nécessaires pour l'installation et la maintenance (ce qui ne veut pas dire qu'il n'en faut pas du tout). Cela me semble un défaut de conception à la source. Surtout que comme je l'ai dis en début de réponse, il y a des alternatives au XML qui font le même boulot en pas plus de ligne et qui sont humainement acceptable.
Bref, je ne sais pas si c'est Red-Hat qui pousse à cela mais libvirt, heartbeat2... Moi, cette voie du XML, cela commence à me gonfler sérieusement. D'ailleurs, pour cette raison, j'évite toute application en java sur mes serveurs dans mon laboratoire et pour le moment, aucune ne me manque.
[^] # Re: virt-manager
Posté par IsNotGood . Évalué à -2.
XML c'est un standard, il y a des outils pour les manipuler.
Le but n'est pas de tout faire avec vi. Mais d'avoir des outils de haut niveau.
De tout manière, c'est un débât dépassé. Il y aura de plus en plus de fichier de configuration en XML. Pour les choses compliquées ça présente trop d'intérêt pour s'en passer (sans compter qu'on n'a pas à ce faire chier a écrire un parser etc).
> Bref, je ne sais pas si c'est Red-Hat qui pousse à cela mais libvirt
Pour libvirt, le choix de XML a été fait dès le début (donc par Red Hat).
[^] # Re: virt-manager
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Le XML est un standard récent qui est bien pour certain truc, notament dans les pipelines de type AxKit. Pour charger une configuration, c'est lourdingue et inutilement compliqué.
Sais tu que charger une configuration en YAML dans un programme se fait en deux lignes, une pour charger la bibliothèque et une pour charger la configuration. Sais tu aussi que le YAML est multiplateforme et multilangage, tout comme les fichiers .ini, tout comme...
Non tu es dans ton petit monde du HTML et du XHTML et donc il faut en mettre partout. Et puis c'est ce que veulent les entreprises alors suivont comme un mouton... Ce n'est pas dans ma philosopie ni celle qui m'a fait adoré Linux depuis des années et des années.
Bref, tu ne me donnes aucun argument qui tienne la route. Donne moi vraiment un truc compliqué parce que la configuration de machine virtuelle, c'est un truc que je trouve assez simple.
Ce que j'en pense, avec des logiciels libre ayant des fichiers de configuration en XML, il faut se tapper absolument une interface graphique de configuration. Or écrire ce genre de programme est super chiant, c'est pas si facile à faire, surtout sans bogue. Les boites comme Red-Hat ont peut être tout intérêt à vendre du support la dessus. En tout cas, c'est par exemple un peu la stratégie de XenSource (Citrix) que de vendre l'IHM de configuration.
Bref, c'est peut être une stratégie commercialle mais certainement pas technique.
Petit exercice pour finir : vous mes traduisez en XML un fichier de configuration conséquent des serveurs apache2 et exim4. Faites de même avec samba. Comparez et tirez en la conclusion qui s'impose.
[^] # Re: virt-manager
Posté par ckyl . Évalué à 2.
Bin non juste un editeur XML digne de ce nom, si le schema a été bien pensé. Bonus tu as la complétion et la validation de ton fichier à la volée. Pas besoin de cycle test/correction
Après je suis pas fan non plus des fichiers de conf en XML. Par contre entre tomcat et apache, la conf du premier est vachement mieux foutue (en dehors de la verbosité).
Le truc, c'est qu'en général on a pas envie de se faire chier à inventer encore un nouveau format, avec encore un nouveau parser, avec encore de nouveaux modes pour chaque éditeur. Alors on prend un truc qu'on a sous la main. Et XML est de loin le truc le plus disséminé en ce moment...
[^] # Re: virt-manager
Posté par IsNotGood . Évalué à 1.
> Le truc, c'est qu'en général on a pas envie de se faire chier à inventer encore un nouveau format
Chaque fichier .ini a son propre format qui n'est pas décrit (sauf dans la doc)...
Je ne dis pas que l'XML doit être foutu partout. Mais aujourd'hui on ne peut plus demander à l'utilisateur de prendre un éditeur de texte pour change une configuration. Aujourd'hui la grande grande grande majorité des fichiers de configuration sont modifiés via un programme (qui n'est évidemment pas un éditeur de texte). XML est excellent dans ce domaine.
Libvirt a-t-il besoin de fichier de configuration en XML ?
Je ne donne pas la réponse. Mais c'est très cool avec virt-manager de créer et modifier une machine virtuelle est quelques cliques au-lieu de se bouffer la doc et utiliser un éditeur de texte (avec tous les risques d'erreur que ça implique). En majorité XML (ou autre) c'est mieux pour l'utilisateur, c'est aussi beaucoup mieux pour les développeurs.
Voyons ces projets :
http://cft.et.redhat.com/
http://augeas.net/
https://fedorahosted.org/func
Si tout était en XML, leurs vies seraient grandement simplifiées (avec contrôle et tout ; par exemple ils détecteraient automatique qu'une modification n'est pas encore supportée avec telle version d'apache).
[^] # Re: virt-manager
Posté par 2PetitsVerres . Évalué à 8.
Mouaif...
s/ini/xml/ et ça marche aussi.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: virt-manager
Posté par IsNotGood . Évalué à -1.
Et comment tu décris le contenu d'un fichier .INI ?
Il y a des dtd pour fichiers .INI ?
Il y a l'équivalent de XPath pour les fichiers .INI ?
> Le XML est un standard récent
Mouaif...
> Les fichiers YAML, c'est un standard, il y a des outils pour les manipuler. .
Tu veux bien des fichiers YAML, mais pas des fichiers XML...
Va savoir pourquoi...
> Et puis c'est ce que veulent les entreprises alors suivont comme un mouton...
Soit rebelle.
> Bref, tu ne me donnes aucun argument qui tienne la route.
Et quel est ton argument ?
Ton argument c'est "XML poua, car c'est à la mode ; je veux un truc qui n'est pas à la mode".
Ben ça ne va pas loins.
> Les boites comme Red-Hat ont peut être tout intérêt à vendre du support la dessus.
C'est du libre. Fock libvirt. C'est beaucoup plus fort que de critiqué ce qui est fait pour et par le communauté.
N'utilises pas libvirt, n'utilises pas Gnome, n'utilises pas Firefox, etc. T'es libre.
> Petit exercice pour finir : vous mes traduisez en XML un fichier de configuration conséquent des serveurs apache2
Ben un fichier de conf d'apache a des ressemblances avec XML. Si c'était en XML, copier programmatiquement la configuration d'un site vers un autre site serait trivial. Mais actuellement il faut faire une usine à gaz pour y arriver.
[^] # Re: virt-manager
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Va savoir pourquoi...
Parce que c'est lisible, je pense.
XML :
<moduleList>
<module name="toto">
<paramList>
<param name="titi">tata</param>
<param name="files">
<file name="/foo/bar"/>
<file name="/baz"/>
</param>
...
</paramList>
</module>
</moduleList
YAML :
modules :
- toto :
titi : tata
files :
- /foo/bar
- /baz
Ou encore :
modules :
- toto :
titi : tata
files : [/foo/bar, /baz]
Franchement, entre le XML et le YAML, il n'y a même pas à hésiter, pour faire des configurations humaines. Parce qu'un fichier de configuration, c'est avant tout fait pour être lu, compris et correct. XML échoue dans les trois cas :
- c'est illisible par un être humain normal,
- c'est encore moins compréhensible sans passer longtemps à déchiffrer,
- si ce n'est pas correct, va trouver l'erreur au milieu de cette syntaxe verbomitive.
[^] # Re: virt-manager
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Pour les configurations humaines, et les autres, sans hésiter, je prends des S-Exprs... Et en plus, comme je code en Scheme, je peux les parser directement et efficacement !
(modules (toto (titi tata) (files "foo/bar" "/baz")))
Et tu peux même en faire un programme à part entière et générant dynamiquement le parseur, et toussaquelisppermet !
[^] # Re: virt-manager
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: virt-manager
Posté par benja . Évalué à 3.
Tant que tu y es, tu vas nous expliquer comment tu génère/modifie/parse la configuration YAML de ton parc de 100 serveurs virtualisés. J'espère que tu ne compte pas le faire à la main...
Bref, YAML ça pue encore plus que le XML. À quoi bon ?
*: - niveaux d'indentation déterminants: beurk, vive le copier-coller !
- peu supporté, pas la peine de me sortir le nom d'une bibliothèque YAML, ce truc est 1000 fois moins supporté que le XML.
- comment fait-on pour valider ton yaml avec un schéma ? (même problème pour les s-expr). Cette tâche doit maintenant être faite par le programme lui-même (charger des nouvelle donnée et regarder si "ça passe")...
- avec XML, les noms d'attributs et les noms de tags décrivent généralement ce qu'ils contiennent. Peut-on en dire autant de ton exemple YAML ? Et les S-Exps ? ah bon, c'est pareil ;-)
[^] # Re: virt-manager
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Pour gérer une configuration YAML, bah, avec Perl/Python/Ruby/Java, n'importe quoi enfin.
Niveau d'indentations déterminant : un bon éditeur de texte permet d'augmenter ou de diminuer facilement le niveau d'indentation de tout un bloc.
Peu pris en charge : tu vois un langage courant pour lequel il n'existe pas de parseur YAML ?
Validation : c'est nouveau, cette manie de vouloir valider des fichiers de configuration ? Mon main.cf, c'est Postfix lui-même qui le lit et me dit si quelque chose ne va pas dedans. Pareil pour smb.conf et tout. Après tout, c'est le programme qui sait de quoi il a besoin.
Noms d'attributs et de balises : en YAML ou en JSON, on peut tout à fait utiliser des dictionnaires ou tables de hachage, donc des noms significatifs.
[^] # Re: virt-manager
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Dis donc, t'es pas sympa avec le XML. Même moi, je n'ai pas dis cela ;-)
Un truc qui m'amuse sur le YAML, les pro XML déteste et parmi ces personnes, il y en a plein qui adore python. Or comme python, YAML est basé sur l'indentation...
Personnellement, je ne suis pas fanat de python et de l'indentation. J'ai pris l'exemple du YAML car c'est ultra simple a utiliser dans un programme, que c'est facile à lire, que cela commence a être connu et que ca gère une bonne partie du CPAN... Donc, on ne peut pas dire que c'est un truc d'amateur qui ne passe pas la mise à l'echelle.
Mais en fait, je n'ai aucune action chez YAML et je suis ouvert à tout format qui soit humainement conçu. Encore une fois, il faut choisir le bon langage pour le bon usage.
Sinon, effectivement, il y a plein d'outil qui ont été fait autour du XML. Si le dixième de cet énergie avait été mis sur un truc humainement lisible, on aurait aujourd'hui quelque chose de vraiment bien. Quand je vois le nombre d'heure année qui ont été passé pour qu'on utilise le XML à tour de bras et lorsque tu vois le nombre d'heure mis, par exemple sur le YAML (zut, encore lui), tu te dis que le XML, en lui même, est un truc complètement pas rentable...
D'un autre coté, le XML a permis de développer tout un tas de technologie annexe, comme la recherche dans un arbre avec XPath... Mais cela, tu pourrais très bien l'appliquer sur un arbre YAML (Ah non, je ne veux plus en entendre parler !) ou sur un format binaire comme HDF.
D'ailleurs, à mon sens, un gros part de ce qui a été fait sur XML aurait du être fait autour d'HDF ou un équivalent. Quitte à avoir des outils de haut niveau pour manipuler l'arbre de données, autant avoir un format binaire optimisé.
Mon pronostic : le HTML quitte peu à peu le web utilisateur puisque celui-ci rédige de plus en plus avec des syntaxes de type wiki. Très peu d'utilisateur pondent encore du HTML directement. Pour le XML, cela va faire pareil. Cela va devenir une technologie que se déroulera en arrière plan de l'utilisteur et il configurera son outil de configuration de sa titanesque application avec un bête fichier .ini ;-)
[^] # Re: virt-manager
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: virt-manager
Posté par Thomas Douillard . Évalué à 1.
Le XML a d'autres atouts, genre plein d'outil pour l'édition, l'écriture, la validation. Voire la génération d'interface de configuration à partir d'un schéma, ce genre de chose.
Après, un fichier de configuration c'est surtout fait pour stocker la configuration d'un logiciel. Et pour manager la configuration d'un logiciel, il y a parfois plus efficace que de taper direct dans un fichier de config, avec toutes les erreurs que ça peut induire.
[^] # Re: virt-manager
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Expérience vécue : je veux activer SSL dans un hôte virtuel servi par Sun Java application server. Réflexe : il est où, le fichier de configuration ? Voyons son manuel… Échec, tout simplement : s'il y a un unique fichier de configuration, il est bien caché, et pas franchement lisible.
La solution, en fait, c'était de fouiller dans l'interface Web d'administration. De quoi sortir dégoûté par ce logiciel.
[^] # Re: virt-manager
Posté par Thomas Douillard . Évalué à 2.
Pour te paraphraser, le logiciel sais très bien ce dont il a besoin ;)
[^] # Re: virt-managerœ
Posté par ckyl . Évalué à 1.
Alors la tu as deux solutions. Tu connais un minimum glassfish, tu as un editeur xml potable (ou tu sais lire une doc et une DTD) et tu rajoutes un beau http-listener à ton domaine et tu oublies pas de l'ajouter aux serveurs adéquat. Ca donne un truc comme ca:
<http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server="server" enabled="true" family="inet" id="https" port="443" redirect-port="443" security-enabled="true" server-name="xxxx.com" xpowered-by="true">
<ssl cert-nickname="s1as" client-auth-enabled="false" ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>
</http-listener>
Tu peux aller voir la DTD http://fisheye5.cenqua.com/browse/glassfish/admin-core/confi(...) (dispo dans ton install dans lib/dtd/sun-domain_1_x)
Si tu veux pas te faire chier tu fais un bete create-ssl, http://docs.sun.com/app/docs/doc/820-4497/create-ssl-1?l=en&(...) . C'est l'avantage du xml tu peux faire des outils faciles pour manipuler les fichiers de conf.
Si tu sais pas faire, ni lire la doc bin tu cliques dans la console d'admin ca va 10x plus vite et t'es sur de pas faire d'erreur...
Ici on se moque souvent des admins windows mais la c'est un peu pareil... Si tu ne connais meme pas l'existance du domain.xml alors le problème c'est toi... A ta décharge on a fait de meilleures doc que celles de glassfish. La conf de tomcat est aussi mieux foutue.
[^] # Re: virt-managerœ
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Bon maintenant, tu as un editeur potable qui marche sans X11 ?
[^] # Re: virt-managerœ
Posté par ckyl . Évalué à 1.
<http-listener
id="https"
address="0.0.0.0"
default-virtual-server="server"
port="443"
security-enabled="true"
server-name="xxxx.com">
<ssl cert-nickname="s1as">
</http-listener>
Compare avec une config apache et explique moi ce qui te choque. Tu ferais comment toi ?
Pour le sans X11 j'édite mes fichiers en remote...
PS: tu peux nous coller des bouts d'exim.cf ou voir de sendmail qu'on rigole un coup :-)
[^] # Re: virt-managerœ
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Un bout d'exim, du coté d'un routeur (vocabulaire exim), en espérant que templeet ne me le mange pas trop (il mange quand même un bout de l'indentation). C'est presque comme du XML avec des <> et des guillemets "" en moins. C'est tout de suite plus léger pour le regards.
dnslookup:
debug_print = "R: dnslookup for $local_part@$domain"
driver = dnslookup
domains = ! +local_domains
transport = remote_smtp
same_domain_copy_routing = yes
# ignore private rfc1918 and APIPA addresses
ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 192.168.0.0/16 :\
172.16.0.0/12 : 10.0.0.0/8 : 169.254.0.0/16 :\
255.255.255.255
no_more
Pour l'edition en remote, j'aime pouvoir travailler en local au cas ou. Et puis en local ou en remote, de toute manière, je suis dans un terminal...
[^] # Re: virt-managerœ
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: virt-manager
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'aimerais bien voir l'interface de configuration d'un serveur comme exim fait via un schéma ?
Je sens que dans ce débat, il y a les pros XML qui m'ont l'air pour les IHM graphique de configuration et les autres. Pour moi, une IHM graphique pour configurer exim me semble une voie glissante vers le clickodrome Windows ou finalement, tu ne comprends pas grand chose de ce que tu fais. Comment répares-tu ce genre d'usine à gaz, bien tu ré-installe comme tout le monde car c'est quasiment pas réparable sauf par un spécialiste quasi inexistant.
Exemple pris sur un logiciel qui n'est pas un serveur : thunderbird. Je ne sais pas vous mais moi, lorsqu'un de mes utilisateurs a un profile qui pars en sucette (et cela arrive parfois malheureusement), je suis incapable de réparé cette usine à gaz et je repars sur un nouveau profile. L'utilisateur est content mais en réalité, je suis d'une grande incompétence.
Je voudrais éviter d'avoir à faire cela sur mes serveurs de mails, mes apaches, mes machines virtuelles, ma haute disponibilité... Je ne me considère pas comme un très bon administrateur système et pourtant, comme des milliers d'autres, j'arrive à réparer des configurations foireuses si celle-ci ne sont pas noyés dans des IHM graphiques et des fichiers de configurations obscurs.
Au final, je me fiche pas mal que le XML ait un schéma qui me permette de valider ma configuration. C'est comme un formulaire web, ce n'est pas au javascript de valider les données mais toujours au serveur. Idem pour un fichier de configuration, le serveur ne doit pas prendre le fichier de configuration pour argent comptant. Tant mieux s'il est juste.
Je préfère que le serveur ait un mode ou il charge le fichier de configuration et me disent lui-même ce qu'il en pense. Normalement, un serveur programmé correctement devrait avoir un mode comme cela. Qu'en interne, celui-ci transforme mon fichier de configuration en XML et lance un validateur de schéma, c'est le choix du programmeur et je le respecte entièrement.
> Après, un fichier de configuration c'est surtout fait pour stocker la
> configuration d'un logiciel
J'ai l'impression qu'il y a peut être là un mélange mais je me trompe peut être. On a l'impression que tu parles de l'état du logiciel. Que le logiciel stocke sont état sous un fomat quelconque pour se relancer plus vite et dans le même état ensuite me convient parfaitement. Dans ce cas là, autant avoir un format binaire type HDF par exemple mais toutes les solutions peuvent être bonne en fonction du contexte. Mais il ne s'agit plus vraiment de configuration (donc de /etc) mais plutôt de données donc dans /var ou /data
[^] # Re: virt-manager
Posté par ckyl . Évalué à 1.
Tu critiques les logiciels que tu ne comprends pas ou qui ont un horrible fichier de conf qui n'est plus ou moins qu'un dump mémoire. Pour ceux que tu ne comprends pas il te suffit de lire la doc. Typiquement la conf d'exim est tout sauf simple mais tu as passé beaucoup de temps pour l'appréhender. Pour les logiques moisies, quel que soit le langage utilisé ca restera moisi.
On peut faire des choses très correctes en les décrivant en XML. La conf de tomcat est simple et bien foutue. Lis les 50 premieres pages de Professional Apache Tomcat et tu seras capable de presque tout faire. C'est pas plus compliqué qu'apache ou exim. Et c'est tout aussi robuste et maintenable.
Après les technos autour d'xml comme la sérialisation automatique poussent certains à la paresse... Pour moi la paresse s'arrête à laisser au parseur toute la validation (validité, type, restriction). Définir un bon fichier de config prend du temps XML, YAML ou ce que tu veux.
Un bon éditeur XML "léger" libre est un gros manque. Pour les devs tu as eclipse/netbeans mais qui font chier avec la gestion de projet et pas adapté aux administrateurs. Autrement tu as quelques bon outils proprio...
> Idem pour un fichier de configuration, le serveur ne doit pas prendre le fichier de configuration pour argent comptant. Tant mieux s'il est juste.
La complétion/validation coté éditeur c'est pour aider l'utilisateur ! En éditant ton fichier tu as accès à la doc en ligne, ton éditeur te propose toutes les options possibles automatiquement, les mots cles/valeures/contraintes d'intégrité sont vérifiées. Bref c'est super pratique, plus de typo ou de trou de mémoire. Et évidement le serveur fait sa propre validation !
[^] # Re: virt-manager
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Sois.
Ben ça ne va pas loins.
Loin.
C'est du libre. Fock libvirt.
Forke ?
C'est beaucoup plus fort que de critiqué
Critiquer.
N'utilises pas libvirt, n'utilises pas Gnome, n'utilises pas Firefox, etc.
Utilise.
[^] # Re: virt-manager
Posté par benja . Évalué à 2.
[^] # Re: virt-manager
Posté par benja . Évalué à 2.
Ensuite dire que les fichiers textes sont entreprise car Unix l'est et les utilise; c'est tout aussi bof. (Unix qui date d'une époque, où XML n'existait pas/ne pouvait pas exister dans sa forme actuelle). The cfengine project was started in 1993 as a reaction to the complexity and non-portability of shell scripting for Unix configuration management, and continues today. (wikipedia), ça m'a l'air toujours très "enterprise" comme truc les fichiers de conf.
Ensuite dire: des arguments que je considère comme fallacieux : "il me faut des méta outils qui puisse me générer mes fichiers de conf"; alors que tu dis exactement la même chose...
Du beau grand troll.
# sous macosX, c'est vraiment pas mal
Posté par toctoc1 . Évalué à 5.
Ben... le moins qu'on puisse dire, c'est que virtualbox est plus véloce, plus réactif. Je viens d'installer un vieil xp qui trainait à la maison : rien à dire, ça déroule.
J'ai également installé une mandriva spring2008. super.
pour répondre à "quel intérêt ce genre de chose?", j'en vois immédiatement au moins un.
Quand tu fais le webmunster comme moi, avec quelques sites en production, il est intéressant de voir en direct, l'évolution de ta page et des modifs que tu fais sous différentes architectures, leur rendu.
là je viens de voir, par exemple que mon site principal merdouille un peu sous kde.
Et j'ai pas eu besoin d'allumer 36 ordi pour le voir.
Adopté chez moi, en tout cas...
[^] # Re: sous macosX, c'est vraiment pas mal
Posté par Kerro . Évalué à 3.
quel intérêt ce genre de chose?
Il y a beaucoup de besoins différents. Dans notre entreprise, j'ai décidé de virtualiser pour que les serveurs Windows fonctionnent plus rapidement (oui oui, plus rapidement en passant par vmware, no comments). Notre seconde grosse raison est la sauvegarde et remise en route: nous copions simplement les images virtuelles. Ca redémarre sur n'importe quel ordinateur (ayant vmware tout de même) et les sauvegardes sont garanties complettes à 200% puisque c'est une bête copie du disque virtuel. Nous avons maintenant une troisième raison: mettre plusieurs serveurs Windows sur une seule machine physique.
[^] # Re: sous macosX, c'est vraiment pas mal
Posté par toctoc1 . Évalué à 1.
imaginons un PC sous winxp. je lance une virualbox avec une mandriva dedans. dans cette mandriva je lance un serveur http avec php-hétoussa.
Depuis windows, puis-accéder à ce serveur via un navigateur?
[^] # Re: sous macosX, c'est vraiment pas mal
Posté par Kerro . Évalué à 3.
imaginons un PC sous winxp
Même pas en rêve :-)
Ta machine virtuelle est un ordinateur comme n'importe quel autre ordinateur. Si tu sais faire fonctionner ton serveur http sur une machine physique, c'est la même chose sur la machine virtuelle.
La différence est que la machine hôte controle les accès disque, réseau, la mémoire etc, ce qui permet de mettre en place des commutateur réseau virtuels par exemple. Tu peux ainsi "brancher" ta machine virtuelle sur un réseau virtuel qui ne peut pas sortir de ta machine physique. Ou tu peux brancher ta machine virtuelle sur la même chose que ta machine physique. Tu peux faire un peu tout ce que tu veux pour filter les paquets, limiter les débits, rediriger les flux.
[^] # Re: sous macosX, c'est vraiment pas mal
Posté par toctoc1 . Évalué à 2.
Merci pour le réponse, je vais creuser l'idée.
[^] # Re: sous macosX, c'est vraiment pas mal
Posté par Gniarf . Évalué à 2.
du coup ensuite c'était http://192.168.0.123 ou bien on rajoutait une entrée 192.168.0.123 pouetpouet dans C:\Windows\system32\drivers\etc\hosts pour avoir ensuite http://pouetpouet ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.