Üdv!
Egy olyan problémával kellett szembenéznem, hogy egy már futó és működő, csak SSH hozzáféréssel (root) ellátott gépre fel kellene húznom egy virtuális gépet, egy-két spéci kitétellel.
Egy Debian Linux 5.0 rendszerről van szó, melyen saját fordítású 2.6.30.x -es linux kernel fut, core2 cpu, kernel modul betoltesi lehetoseg kikapcsolva. A szerveren nem fut semmiféle grafikus alkalmazás (se gnome se egyeb nincs feltelepitve), framebuffer sincs fordítva a kernelbe, illetve van fent grsecurity.
Több más szerveremen haszálok XEN-t, VMWare-t, VirtualPC-t es VirtualBox-ot is, illetve ezen a gépen eddig egy OpenVz+grsecurity combo-ban futtattam virtualis operacios rendszereket, tehat nem idegen tolem a virtualizacio, megis elakadtam. Alapvetoen meg voltam elegedve az eddigi megoldassal is, de alaplapcsere miatt a 2.6.20-as kernelt mar le kellett cserelnem (ez volt az egyetlen, amihez az OpenVZ-sek megcsinaltak a grsecurity-vel osszehazasitott peccsüket). OpenVZ használatát a grsecurity tamogatas (RBAC, apache socket vedelmek aktivan vannak hasznalva a gepen) hianya miatt el kellett vetnem (XEN-t a modulok miatt, a VirtualBOX-ot meg lassusaga es X igenye miatt). Linux KVM qemu-val kezenfekvonek tunik, es velhetoen mukodne is, (bar a quemu -t elotte soha nem hasznaltam meg, de alapvetoen mindegyik virtualizacio egy kaptafara megy hasznalati oldalrol) csak sehogy nem sikerul ravennem arra, hogy tisztan szoveges modban, ssh-n keresztul fel tudjak tenni egy virtualis rendszert.
Szepen elkeszitettem a virtualis gepet:
qemu-img create -f qcow2 ./vdisk.img 2260M
majd megprobaltam egy debian iso telepitot elinditani (defaultban a "cdrol" bootol):
/usr/bin/qemu-system-x86_64 -hda ./vdisk.img -cdrom /home/eliast/debian-503-i386-netinst.iso -boot d -m 384 -smp 2
ekkor kaptam a Framebuffer alrendszerre vonatkozo anyázást (elotte grsec is okadott, de aztan chpax -pemrxs megoldotta), miszerint nincs. Ám legyen, tud ez a nyavaja futni enelkul is, ncursest hasznalva, igy a fenti megoldást kiegészítettem:
/usr/bin/qemu-system-x86_64 -hda ./vdisk.img -cdrom /home/eliast/debian-503-i386-netinst.iso -boot d -m 384 -smp 2 -no-frame -curses
Szépen el is indul a debian telepito, loading vmlinuz, initrd stb...
Azonban ezt kovetoen amikor a telepito menujet kene latnom kapok egy szep kiirast, hogy 640x480 Graphic mode. Es ennyi.
Es ebbol az allapotbol sehogy sem sikerul kimozditani. Amennyire ezt jol ertelmezem, a debian telepito valamiert nem szoveges modban indul el, igy a 640x480 persze hogy megfekszi a putty gyomrát. Ezekután azonban hiaba probalkoztam a
/usr/bin/qemu-system-x86_64 -hda ./vdisk.img -cdrom /home/eliast/debian-503-i386-netinst.iso -boot d -m 384 -smp 2 -no-frame -curses -append DEBIAN_FRONTEND=text fb=false
illetve a
/usr/bin/qemu-system-x86_64 -no-acpi -hda ./vdisk.img -cdrom /home/eliast/debian-503-i386-netinst.iso -boot d -m 384 -smp 2 -no-frame -curses -append "install DEBIAN_FRONTEND=text fb=false debian-installer/framebuffer=false"
megoldsokkal, valamint kinomban mar arra gondoltam, hogy magat a quemut inditom grafika nelkuli modba (-nographic mert ezt a cuccot elvileg sorosporton keresztul is lehetne installni), es egy screen sessionre iranyitom az egeszet, de ez sem jart sikerrel, mert a sessionre rascreenelve csak egy szep fekete kepernyot kapok.
Mindezeken tul probaltam forceolni a debian cdn levo default kernelt, a "-kernel /install.386/vmlinuz" parameterrel, de semmi valtozas. Olyba tunik nekem, hogy a telepito minden esetben atkapcsol 640x480-as modba. De miert?
Van e esetleg valakinek otlete, csinalt-e mar hasonlot? Mert en itt kifogytam. (persze lehetne modositani a debian installer isot hogy lapbol textmodu telepito induljon el, ezzel meg valo igaz nem probalkoztam, de az iso ujracsomagolasahoz nem sok kedvem van, valami szalonkepesebb megoldas kene, amit egy 128k-s vonal vegerol is vegig lehet csinalni. :) )
Koszonom. :)
ui.: Tehat a kerdes: debian 5-os guest feltelepitese guest OSnek grafika nelkul egy szinten grafika nelkuli tavoli gepen csak SSH login lehetosegeit kihasznalva?
- 1632 megtekintés
Hozzászólások
qemu tud vnc-t
ez kell parancssorba meg: -vnc :0,password -monitor stdio
aztan "change vnc password jelszoamitakarsz"
- A hozzászóláshoz be kell jelentkezni
Üdv!
Csodalatos, mukodik, figyel a vnc. Mas kerdes hogy sajnos nem megyek vele semmire, mert egy kozbeneso tuzfalon nem megy at az 5900, tehat max vmelyik szolgaltatas lelovesevel es annak a portjara valo felkonfolassal lehetne idolegesen megoldani ezt az ugyet... Hm. Belepek sshn, lelovom openssh-t, akkor felszabadul a portja, mert a kiepitett kapcsolat mar ugyis a magas portokon megy, az eredeti sshra rakonfolom ezt a vnc-t (ha lehet), beallitom ezt a szart, aztan raprobalkozok konzolbol.... aztan ha vegeztem ssh ujra elindit.... Alapvetoen ez lesz, de ha netalantan lenne meg valakinek otlete, a vnc nelkuli megoldasra, kerem ne fogja vissza magat.
Köszönöm!
----
Too many people making too many problems...
- A hozzászóláshoz be kell jelentkezni
ssh-n tudsz port forwardot csinálni, arról nem is beszélve, hogy a disket be tudod mountolni a gazdarendszer alá és abban futtatni egy debootstrapet vagy egy működő rendszert odamásolni, fstabot átírni, stb.
- A hozzászóláshoz be kell jelentkezni
Hm. Belepek sshn, lelovom openssh-t, akkor felszabadul a portja, mert a kiepitett kapcsolat mar ugyis a magas portokon megy, az eredeti sshra rakonfolom ezt a vnc-t (ha lehet), beallitom ezt a szart, aztan raprobalkozok konzolbol.... aztan ha vegeztem ssh ujra elindit...
Egyéb ötletem nincs, de ez így nagyon merész!
- A hozzászóláshoz be kell jelentkezni
erre szerintem nem a merész a megfelelő jelző, hanem a marhaság.
az ssh kapcsolatot nem fogja átpakolni másik portra a szerver.
másrészt az ssh képes forwardolni egy tcp forgalmat (talán udp-t is, de azt még soha sem használtam)...
Szóval localhost egy portját átforwardolod a távoli gép vnc portjára és akkor localhoston kell vnc-re kapcsolódni. Az szakmailag nem állja meg a helyét, hogy leállítod az sshd-t...
- A hozzászóláshoz be kell jelentkezni
Üdv!
Nem is pakolja át. A lenyeg, hogy a vnc-t ra tudjam bindelni idolegesen. Es ha az ssht leallitom akkor a port amin figyel az felszabadul. Az aktiv kapcsolat meg termeszetesen nem zarodik le, hiszen annak mar semmi koze az eredeti ssh porthoz, hsizen uj processz, uj porton nyomja az established kapcsolatot....
Az sshs portforward is biztosan jo lett volna, de mostmar mind1 is, a lenyeg hogy mukodott a favágó modszerrel is, sshjat amugy is csak nehanyan hasznaljuk...
----
Too many people making too many problems...
- A hozzászóláshoz be kell jelentkezni
természetesen minden ssh processz, amelyiket a 22-es porton futó ős-sshd indított, a 22-es porton fut továbbra is. Ezt a semmi köze az eredeti ssh porthoz szöveget mellőzni kellene az erősebb jelzők megérkezése előtt.
- A hozzászóláshoz be kell jelentkezni
esetleg debootstrap?
udv Zoli
- A hozzászóláshoz be kell jelentkezni
nem hinném, hogy erre a hozzászólásra vártál, de
én eddig (-2 hónap) csak a xen-t használtam (1,5 éve) (opensource, csak konzol), de most kipróváltam a proxmox ve megoldását,
és egyenlőre nagyon szimpatikus.
debian lenny alatt megy (bár én egyből iso installal tettem fel, de van módszer csupasz debianra is feltenni)
openvz és kvm virtualizációt támogat, webes felületen kezelhető és ott szépen be is hozza a virtuális gépeket java vnc
kliensel.
http://pve.proxmox.com/wiki/Main_Page
bár gondolom meg lehet kvm -el csinálni csupaszon is, amit itt összeraktak, de nálam ez nyert egyenlőre.
- A hozzászóláshoz be kell jelentkezni