J'ai une vielle machine, et j'aimerai y installer Linux (car j'aimerais m'y mettre). Seulement, je possède seulement un vieux clavier et d'une vielle souris. Je voudrais savoir s'il serais possible d’accéder au Linux depuis mon actuel Windows en local via PuTTy ou autre?
Il me faudrait acheter une carte réseau pour accéder en local, ou un câble réseau serait fonctionnel ?
Avez-vous des conseils sur le choix du Linux ?
Pourrait-on avoir plus d'infos sur ta vieille machine pour t'aider dans le choix de la bonne distribution ?
Sinon, si le but c'est de t'en servir en console uniquement, et que la machine en question possède une carte réseau et un câble relié à ton PC Windows (l'achat de ces deux éléments est donc peut-être à prévoir, pour un coup d'environ 10€ en grande surface), tu peux bien entendu y accéder via PuTTY sur une connexion locale (néanmoins tu devras y brancher un écran pour faire l'installation initiale, et il faudra installer openssh-server). Il y a plein d'infos disponibles sur Internet sur comment configurer ces deux machines en réseau local, je te laisse chercher un peu pour ça.
Bonjour !
Je pense que le PC contient déjà une carte réseau.
Au niveau du matériel il te faut donc simplement un câble réseau pour relier les deux PC.
Utiliser cet ordinateur est une bonne idée pour te faire la main sur du linux, mais je te conseillerais d'utiliser une machine virtuelle sur ton windows actuel si ta configuration te le permet.
Virtualiser des environnements de tests ou de bidouille est vraiment très intéressant. Si tu casses tout, il est beaucoup plus rapide de deployer une machine virtuelle, plutot que de tout réinstaller sur ton PC DELL.
VirtualBox marche très bien, il n'y a aucun intérêt à accéder une machine virtuelle locale par du ssh, excepter peut-être pour le test.
Les pré-requis pour une connexion ssh :
- avoir 2 machines : 1 client, 1 serveur
- le serveur contient le logiciel ssh serveur (openssh-server) et le service est DEMARRE
- le client contient un client ssh sur installé par défaut sur linux
- une configuration réseau fonctionnelle (adressage + aucun firewall ne bloque le port 22 nécessaire à la liaison ssh)
Il reste toujours les autres :
Ton PC Client avait une IP dans le même réseau local que le PC serveur ?
Le service openssh-server était bien démarré sur le PC serveur ?
Aucun Firewall ne bloquait le port 22 ?
Le problème étais qu'avec l'IP locale de la machine, je n'arrivais pas à accéder à la machine.
Pour accéder à une virtuelle en SSH depuis un autre poste, le plus simple est de configurer un accès par pont (mode bridge en anglais). La machine virtuelle se connectera comme n'importe quel PC réel de ton réseau.
Corriger-moi si j'me trompe, mais il faut paramétrer la machine virtuelle avec le bon type de carte réseau pour que les 2 machines (réelle et virtuelle) se voient.
Copier/Coller, transfert de fichiers (SCP, SFTP) ? Ça me fait 2 bonnes raisons déjà. Bref.
Pour l'OS, je conseille Debian. C'est répandu (beaucoup d'aide), léger (la VM qui m'a servi à faire de la QA sur ZdS consommait 44 Mo de RAM en idle), et simple d'utilisation.
Sinon, sortir "Ouais, fais une VM avec VirtualBox", c'est juste pas du tout la même chose. Installer un OS sur une machine réelle est beaucoup plus intéressant que faire une VM, notamment parce que c'est réel, pas juste une fenêtre avec un fichier en tant que disque dur. Et derrière, une machine réelle permet d'ouvrir sur des possibilités futures bien plus grandes, comme par exemple mettre en place un système d'hypervision basé sur Xen (faut pas tenter KVM, le CPU n'a pas VT), ou bien des containers LXC, et par exemple pouvoir s'auto-héberger un petit serveur (Web par exemple).
Bof, normalement même en NAT ça passe le réseau entre l'hôte et la VM. Au pire, VBox propose maintenant un mix entre NAT et réseau privé hôte qui est pas dégueu.
Sinon @Ezenku, Il existe des moyens pour faire du PXE sans carte réseau compatible (virtuelle comme réelle), comme par exemple Etherboot (un utilitaire de boot PXE sur disquette, ça marche plutôt bien).
Copier/Coller, transfert de fichiers (SCP, SFTP) ? Ça me fait 2 bonnes raisons déjà. Bref.
Si je comprends bien son environnement actuel est un windows et un futur linux.. Donc un SCP nécessite WinSCP ou cygwin. Par ailleurs, je vois pas en quoi ces actions sont impossible sur une machine virtuelle..
Chacun son point de vue.
En ce qui me concerne quand je veux faire des tests je lance l'install d'une VM, je fais mes tests et si c'est concluant là, j'investis éventuellement dans une machine physique. Dans la situation présenté par Mhaux, il possède déjà la machine alors évidemment on est d'accord c'est l'occasion!
Bof, normalement même en NAT ça passe le réseau entre l'hôte et la VM. Au pire, VBox propose maintenant un mix entre NAT et réseau privé hôte qui est pas dégueu.
Je ne connaissais absolument pas ce mix. J'ai mis à jour mon Virtualbox, il faudra que je pense à me renseigner là-dessus.
Et derrière, une machine réelle permet d'ouvrir sur des possibilités futures bien plus grandes, comme par exemple mettre en place un système d'hypervision basé sur Xen (faut pas tenter KVM, le CPU n'a pas VT), ou bien des containers LXC, et par exemple pouvoir s'auto-héberger un petit serveur (Web par exemple).
Tu as déjà fait ce genre de choses ? Ça m'intéresse.
Sinon @Ezenku, Il existe des moyens pour faire du PXE sans carte réseau compatible (virtuelle comme réelle), comme par exemple Etherboot (un utilitaire de boot PXE sur disquette, ça marche plutôt bien).
Ah exact ! J'avais vu ça dans un magazine mais je n'y aurais jamais pensé, merci. Tu as déjà testé ?
Si je comprends bien son environnement actuel est un windows et un futur linux.. Donc un SCP nécessite WinSCP ou cygwin. Par ailleurs, je vois pas en quoi ces actions sont impossible sur une machine virtuelle..
La question était sur l'intérêt d'accéder en SSH à une machine virtuelle, pas sur la différence virtuelle/réelle.
Ouais, avec Xen, VMWare ESXi, libvirt (interface à KVM) et Proxmox (interface à KVM) dans le cas de la virtu complète, et OpenVZ ainsi que LXC pour les containers (ma préférence va à LXC). Mon projet de fin d'année de cette année à Supinfo était basé sur ça d'ailleurs, j'avais un hyperviseur KVM sur un PC avec VT (qui hébergeait ~15 VMs) et sur un autre un hyperviseur Xen qui faisait de la paravirtualisation (le processeur hôte ne supportant pas VT) pour virtualiser un SAN (avec DRBD et accès dual-primary aux disques via NFS).
Ouais, pour les deux. J'ai un ordi assez vieux sans carte compatible PXE, j'ai fait booter une distro optimisée pour le cluster computing (KestrelHPC) dessus.
L'hypervision, c'est de la virtualisation plus poussée que VirtualBox, généralement orientée vers les serveurs plus que les postes de travail. L'idée c'est qu'au lieu d'avoir le système de virtualisation fonctionnant entièrement en dehors du noyau de ton OS (comme VirtualBox), l'hyperviseur va avoir le coeur de la virtualisation fonctionnant dans le noyau du système (qui est généralement un système léger dédié à l'hypervision) et déléguant beaucoup de cette utilisation au matériel, généralement en utilisant des technologies d'accélération de virtualisation comme Intel VT (même si VirtualBox et VMWare Workstation les utilisent aussi maintenant et donc sont partiellement des hyperviseurs). Les hyperviseurs ne proposent typiquement pas des trucs hype comme l'intégration souris automatique ou le presse-papier partagé, mais par contre proposent des fonctionnalités plus orientées serveur comme l'IOMMU (avec Intel VT-d), permettant de transférer complètement l'utilisation d'une carte PCI/PCI-E à une VM, ou des schémas réseau complexes entre VMs.
Bref, c'est de la virtualisation pour les serveurs.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte