a legfrissebb VirtualBoxot telepítem.

sudo apt-get install virtualbox vagy letöltöd a virtualbox.org-ról?

van valami indok arra, hogy miért virtualbox? szerintem a kvm egyszerűbb.

Volt mindkét verzió. De a legtöbbször letöltöm. 2 esetben viszont a parancssoros megoldás volt.
Annyi, hogy a hibát beírva a keresőbe, már a mai napon találtam Bug reportot az ubuntu-nál. Ott is egy csóka ugyanazokat végig próbálta mint én, de nem sikerült neki, aki meg a ticket-et kezelte, az nem tudta produkálni a hibát.

@bambano: Vagrant-hoz kell a VirtualBox, KVM-et egyszer próbáltam, de nem jött össze, viszont ott lehet valamit én rontottam el, mert rendkívül sok cuccot kellett telepíteni a terminalban, és a parancsok több mint felét nem is értettem, hogy mire való, de a hsz-ek alapján másnak működött, nekem meg nem.

1. Csomagból telepítsd. sudo apt-get install vbx akármi.
2. Kernel modul kell, ha tudod, akkor régebbi kernellel indítsd el, ahhoz keress modult, meg header csomagot.
3. Figyelt a bugreportot - mondjuk nem ártott volna ide is linkelned, naénaztán nem fogom túrni a zubuntu bugzilláját... - ha ott írják, hogy friss kernel be javítva, onnantól azt használd.
4. nem ártana még neked is visszajelezned ott, hogy nálad is hiba vna. Akkor valószínűbb, hogy javítják.

Lehet megpróbálom a PCI passthrought, mivel a gép elvileg támogatja (VT-d és VT-x támogatottak). Csak félek, hogy ez azért annyira nem erős gép, hogy virtualizálva játszak, nem tudom, hogy ezen a PCI passthrough mennyit segít, mennyivel gyorsabb egy sima virtualizációhoz vagy Wine-hez képest.

Valamelyik hétvégén megcsinálom, mert kíváncsi vagyok. Bencs Márkicát gondolom a játékok beépített benchmarkjaval csináljam? Vagy valamelyik 3Dmariskával?

1. Volt olyan scenario is.
2. Az is volt, láttam erről leírásokat.
3. Igaz, meg is teszem, itt a link, már írtam is hozzá.
4. Most jeleztem. Igazából a Chromium is bugreport után nem volt kedvem jelezni.

Ami nekem feltűnt, hogy amikor a PC-n volt telepítve csak maga az Ubuntu, és nem UEFI-ben, akkor nem volt gond.
Most UEFI-ben a Windows 10-el, gond van 16.04.2 LTS, 16.10 és 17.04-en is. (Ha magában volt a 16.04.2 LTS legacy módban, akkor felment)
A virtualbox rákérdezett, hogy kikapcsolja-e a 'secure boot'-ot. Ha igen, vagy nem-re mentem, ugyanaz a hiba kód jött.

Ezt megírtam, szerintem valahol itt lehet a probléma.

Üdv a szakinak,
Segítséget illetve tanácsot kérnék az alábbi feladat megoldásában:

Adott egy Natolt hálózatban ülő dedikált backup szerver (Debian), továbbá 4-5 a neten fellelhető szintén Debian szerver, melyekről automatikus mentést kellene készítenem. Eszköznek az rsync használható.
A gépek egyikére sem lehet root-ként bejelentkezni közvetlenül (jelszót sem tudom), a userem viszont mindenhova sudoer.

Három lehetőséget látok egyelőre:

1: a backup szerverre írom meg a scriptjeimet, rsync ssh-n (kulccsal) szépen magára húzná szerverenként a mentéseket. Ehhez terveznék minden szerverre dedikált backup usert létrehozni, akinek viszont minden mentendő mappához ugye nincs/nem lesz joga (/root, /etc...). Ezért is a mentendő szerverekre a dedikált backup user(eke)-t szükséges felvennem sudoer-ként NOPASSWD-vel a /usr/binrsync futtatására, egyelőre más megoldást nem találtam, hogy sudo rsync-ként tudjon ügyködni a remote gépeken. Ez nem annyira tetszik, már csak ezért sem:
[link]
Előny, (ha jól látom) hogy kevesebb esély van a backup szerver törésére ha a remote szerverek kompromittálódnak.

2: a backup szerveren rsync daemon futna, és a scripteket a remote szervereken futtatnám, ssh-n keresztül becsatlakozva. Itt ugye többletmunka (és rizikó) a szerverekről a portok kinyitogatása, továbbá a forgalom egyenkénti beforgatása a backup szerver felé. Továbbá itt kevésbé érezném, hogy a backup szerver biztonságban van.

3: a backup szerverre tolnák fel a szerverek a mentéseket, kihagyva a backup-on az rsync daemon módját. Bár őszintén szólva egyelőre még a daemon módnak az előnyét sem látom. Előnyök hátrányok nagyrésze -gondolom- megegyezik 2-es ponttal, annyi különbséggel, hogy ssh elérések adottak.

Minden ötletet, javaslatot, kritikát szívesen fogadok. A csináltassam meg hozzáértővel most nem opció..

Köszönöm!

udv
letix

egy lehetséges részlet:
knockd

ezzel meg lehet oldani, hogy csak akkor legyen nyitva a port, és oda, ahol kell.

Helló,

Mondjuk azt nem mondtad, hogy rendszert v adatokat v mindkettőt szeretnél menteni.
Duplicity-t ajánlom figyelmedbe igazi mentős svájci bicska. (verzió követés etc..)

Köszi a válaszokat.

Igazából mindkettőt szükséges adott időközönként. Más mentőeszköz egyelőre nem játszik, nem az én rendszereim..
Egyelőre azt nem tudom, hogy a remote szervereken hogyan tudom elérni a mentendő mappákat root nélkül.
sudo-val megy, de ott ugye jelszót kér.. Ami kiküszöbölhető a sudoers-be NOPASSWD -vel csak a sudo rsync-re, csak kérdés hogy ez mekkora biztonsági kockázast.
Köszi,

udv
letix

a root felhasználóhoz is be tudsz jelentkezni SSH kulccsal, akkor nem kell jelszó

Igen, közben én is beláttam, hogy ez is egy lehetséges alternatíva.

A kérdés, hogy melyik rejt több biztonsági kockázatot:
-távoli szervereken a root publikus kulcsának használata a backup-on belépéshez és rsync-hez?
-távoli szervereken a dedikált backup userek sudoers ALL=NOPASSWD /usr/nin/rsync beállítása?

Köszi!

udv
letix

attól függ a dedikált user hogyan lép be? ha jelszóval, akkor a jelszó ismeretében egy mozdulat root jogot kérni.
ha az is kulccsal, akkor szerintem mindegy, hisz akkor mindkét esetben egy olyan user fog belépni, aki rootjoggal rendelkezik, de talán mégis jobb, ha ez nem a root, hanem egy másik név

én a dedikált user + SSH key kombinációt csinálnám

Sziasztok,

Lenne felétek egy olyan kérdésem, hogy hogyan lehet megváltoztatni a "boot" sorrendet CentOS 7 alatt?
Arra gondolok, hogy mikor bootolok a CD-ről vagy pendriveról akkor ugye kapok egy ilyen képet és ugye itt az első opció van kijelölve (Install CentOS 7) aktív. Hogyan lehet megváltoztatni, hogy mondjuk a második menü legyen aktív? Tehát valahogy a telepítő imagen belül?
Köszi!

Arra gondoltam, hogy mind a backup szerveren, mind pedig a távoli gépeken dedikált userek lesznek, így talán tisztább.

Amit még egyelőre nem értek:
Ha az előbbi javaslatod használnám: hogyan tud jelszóval belépni, ha ütemezett script-ből rsync -e 'ssh -p port' formát használok?
Ha az utóbbit, akkor az ssh belépés tisztázott, viszont az --rsync-path="sudo rsync" még mindig jelszót kér a nopasswd nélkül. (és ez a gond fennáll az elsőnél is.)

Én látok valamit nagyon rosszul?

Köszönöm!

udv
letix

Addig is, míg nem kerítek rá sort, íme egy teszt. Ha ez tényleg igaz, hogy csak 2-5% különbség van a natív host és a VT-x+VT-d+PCI-passthrough megoldása között, akkor így, virtualizálva fogok csak Wint használni. Mondjuk így is sajnálom rá a gigágat, értékes tárterületet vesz el, lehet a Wine annyiból nyerő, hogy annál nem kell komplett Windowst tartani, viszont azon nem fut minden, meg még lassabb a natívhoz képest.

hogyan tud jelszóval belépni, ha ütemezett script-ből rsync -e 'ssh -p port' formát használok?

--password-file kapcsoló, amivel megadsz egy fájlt, amiben usernév:jelszó formában tárolod a jelszót, de ezt azt hiszem nem kell részleteznem, hogy miért ne használd...

az --rsync-path="sudo rsync" még mindig jelszót kér a nopasswd nélkül

rsync -rsynceskapcsolók "ssh p port" --rsync-path="sudo rsync" usernév@remotehost.com:/távoli/elérési/út /lokál/elérési/út

így néz ki a tiéd?

Szerintem ehhez saját telepítő készletet kellene kreálnod, ami azért nem triviális.
Mihez kell ez?

Igen, így használnám az rsync-et.
A --password-file jó lehetne, elvégre ez a file a backup gépen lenne, amihez rajtam kívül csak 1 fő ér hozzá, ráadásul netről nem érhető el, viszont ezen opció csak az rsync daemon módjában használható. Ezt viszont én nem tervezném beüzemelni a remote szervereken érthető okokból.

Ha megfordítanám a daemon módot és a backup szerver lenne az rsync daemon, ahhoz szükséges lenne a távoli gépekről elérést biztosítani a backup felé. Ezt viszont már korábban kizártam

Köszi a segítséged.

udv
letix

ISO-ban legacy bootnál isolinux mappában vagy EFI bootnál EFI/BOOT mappában az grub.cnf file-t és átirod benne amit szeretnél. Vannak még ott másik file-ok is ha mégjobban bele szeretnél túrni.

(btw a legjobb ha az embernek van egy pxe szervere és oda azt tesz bele amit akar)

Köszönöm szépen a választ! Kedden amint bemegyek melóba(oda kellett az infó) ki is próbálom.

Nem tudom hogy nézted-e, de 2 GPU, 2 egér, és 2 billentyűzet kell. Utóbbi kettő azért mert ha emulált lesz akkor nagyon fog lagolni ami játékhoz nem jó. Legelső meg a GPU passthrough-hoz kell és egyébként ez nem akkora gond mert ma már minden Intel prociban van egy.

KDE-s problémám van, nem indul el a gwenview. sem üresben, sem képet megnyitva, sem grafikus felületről, se terminálból.
sehol, semmi hibaüzenet...
mi baja lehet? vagy hol nézzem egyáltalán, hogy mi baja...

Valamilyen feladatkezelő vagy ilyesmiben nem látszik? Általában akkor van ilyen jelenség amikor az adott program már fut a háttérben csak beragadt, vagy zombie vagy ilyesmi.

újraindítás után is ez van.

Helló.

Az iiyama t2452mts multitouch monitorokhoz van driver? Fedora 25-n próbáltam, de valamiért az érintési pont jobbra kb 200px-xel arrébb történik állandoan. Ubuntu 16.04 alatt pedig jó az érintési pont, de ott meg csak ennyi műkődik, mozgatni nem lehet az ablakokat. Vagy lehet csak más DE-t kellene használni?

A GPU-ból, billentyűzetből, egérből nem feltétlen kell hozzá kettő. Lehet egyet is használni, csak nyilván a teljesítmény nem lesz olyan. Meg ha mindenből végigvisszük ezt a legyen kettő kezdetű koncepciót, akkor könnyen eljutunk oda, hogy virtualizáció sem kell, legyen két külön gép. Egyébként nekem ezzel a virtualizációval még mindig az a bajom, hogy csak az átbootolást oldja meg, de Windowst épp úgy kell tartani, ami épp úgy foglalja a háttértáron a sok gigákat feleslegesen, csak azért, hogy az ember 1-2 játékkal játszik. Akinek terás tárhelye van, annak nem gond, de nekem laposnál gond, főleg, hogy az SSD is max. csak 256-os lesz, 512-esre nincs pénzem (vagyis van, de nem ilyen hülyeségre akarom elverni), meg a HDD is csak 500-as, és még torrentezek is, utóbbin meg nem linuxos .iso-kat kell érteni, meg nem SD-s anyagokat.

Lehet inkább a Wine-nek adok esélyt, újabb játékot nem próbáltam még benne.

Ha csak 1 GPU-d van hogy oldod meg a passthrough-t? Mert ez konkrétan azt jelenti hogy a guest egy az egyben megkapja a GPU-t úgy, hogy a host abszolút nem fogja tudni használni.

Szerintem nem néztél rendesen utánna, kötelező 2 GPU.

Nem kötelező, VT-x-szel annyifelé passzolod a GPU-t, ahányfelé van bátorságod.

Valami praktikus dolgot mutass mert minden leírást (amit találtam) ami aktuálisan a létrehozást mutatja, 2 GPU-t használ.

Akkor bukó mégis csak, 1 GPU-m van csak. Még jó, hogy ezt tisztáztuk, még mielőtt elkezdtem volna virtuális gépet telepítgetni.

Figyelem, JúBájgönt várják a linuxos SSD blogposztja alá! Figyelem, JúBájgönt várják a linuxos SSD blogposztja alá! Samsung 850 discard TRIM a téma. Szolgálati közleményünket hallották!

letöltöd ezt, lefuttatod, a kapott eredményt a xorg.confba teszed

Közben kicsit faragtam a dolgokon, hátha hasznos valakinek.

Amennyiben a backup gépről egy dedikált felhasználó futtatja a backup scriptet (rsync -a opcióval), úgy a jogosultságok ugyan átjönnek, de a user/group tulajdonságok nem.
Ezt úgy tudtam kivédeni, hogy legyártottam a backup gépen a root publikus kulcsát, ezt hozzáadtam a távoli gép dedikált user authorized_keys-hez , aki egyébként így sudoer az adott távoli gépen:

username ALL= NOPASSWD: /usr/bin/rsync --server --sender -logDtpre.iLsfx . /

Így a user/group tulajdonság is átjön, és talán az rsync-el sem lehet a sudo miatt okoskodni nagyon.
Persze az első sudo rsync futásnál belefut a "Great power comes with great responsibility" felszólításba és meg is akad (no tty..), szóval ezt helyileg egyszer kezelni kell.

Ötlet valakinek?

Köszi,
letix

Több éves Arch-openbox rendszeremet váltottam KDE-re. (tudom mazochista vagyok, de most ehhez volt kedvem).
Az évek alatt valamit beírtam/elírtam, mert most úgy néz ki mintha a KDE mögött futna egy openbox. Néha feltűnik a régi conky és a háttérlépem is.
A KDE bejelentkezését az SDDM vezérli. A régi .initrc-t már kilőttem (átneveztem) de a probléma megmaradt.
Mit lehet még megnézni ami okozhat ilyet?

Töröld le a KDE konfig könyvtárát a saját home-odból.

Itt pl. ugy tunik, hogy ua. GPU-t is tudod hasznalni. Raadasul kollegam is csinalta a korabbi cegemnel es azokban a ThinkPadekben is csak 1 integralt intel vacak volt.

Amit linkeltél, ott arról az esetről van szó ha 2 ugyanolyan GPU van, ami azéárt problémás mert ugyanaz lesz az ID-jük, és ilyen esetben mit lehet tenni.

Intel-nél úgy tudom csak Iris Pro-val lehetséges, mással nem. De azt meg nem raknak Thinkpad-be mert egy szemétláda cég.

Megtettem... miért is kellett? Jobb nem lett, de legalább rosszabb sem

Feltettem egy szűz kde-t is egy másik partícióra. Az hamarabb bootol (miután beállítottam olyanra amire nekem kell).
Egetverő külömbég, hogy a friss install a jelszó után cc 2-3 mp-vel már van asztalom, és utánna kapcsolódik a hálózathoz.
A régivel, meg már jócskán felépült a hálózatot (wifi), miután asztalom lesz.

Be lehet állítani a beállítások között hogy másik ablakkezelővel működjön a kwin helyett. Ha letörlöd a beállításokat akkor visszaáll default-ra, de ezek szerint vagy csak képzelted hogy openbox-al ment, vagy nem törölted rendesen.

[link]

[link]

[link]

[link]

Jól töröltem.. és lehet, hogy húsvét délutánján, már csak képzelem
Mindenesetre, mióta töröltem a conky-t, már nem látom.
A lassabb betöltést még vizsgálom.

Egyébként nem tudjátok, hogy a képen látható naptárat milyen paranccsal hívhatom elő (parancssorból)

Szerintem elég jó az angolom... A lényeg az, hogy lehet egy VGA-val passthrough-t csinálni, csak ne felejtsd el a virtuális gépet automata indulásra tenni. AMD-vel még azt is meg lehet csinálni reboot nélkül, hogy visszaveszed a hostra a VGA-t.

Na hát ez az, ne felejtsd el automatikus indulásra bírni mert a host-tól már nem várhatsz képet mert nem tud mit használni már

Ez értelmetlen a mi esetünkre, akik aktívan szeretnék a host-ot és guest-et is használni, így ugyanott vagyunk mint dual-boot-al. Illetve nem mert ezt sokkal bonyolultabb és időigényesebb összehozni.

AMD-re a módszer elég bonyolultnak, és úgy tűnik nem biztos hogy minden esetben működik is. Meg nincs is AMD-m

Én még mindig maradok a dual-boot-nál, bár meg tudnám csinálni, van egy Intel+nvidia kombó a gépben. Csak az egér gémer, azt is át kellene adni, akkor kell még egy másik egér, meg a sok szenvedés, eh...