- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Magga: PLEX: multimédia az egész lakásban
- Hieronymus: Három júniusi képem
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- sziku69: Fűzzük össze a szavakat :)
- Gurulunk, WAZE?!
- VoidXs: Tényleg minden játék optimalizálatlan?
- Android másképp: Lineage OS és társai
-
LOGOUT
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
Frawly
veterán
válasz
sh4d0w
#26996
üzenetére
Így van, ezt magyarázom én is, hogy ha LUKS van az LVM fölött, akkor minden egyes kötet feloldásához külön jelszó/feloldás kell, ami nagyon kényelmetlen. Csak akkor éri meg, ha az LVM egy részét nem akarja valaki titkosítani, vagy annyira paranoiás, hogy több jelszót is be akar mindig adagolni. Sokkal jobban megéri azért az, amit először írtál, a RAID-LUKS-LVM-FS sorrend, ez az, ahogy a legcélszerűbb minden szempontból, és alapból megéri az egész lemezt titkosítani.
-
Frawly
veterán
válasz
bambano
#26994
üzenetére
Ebben igazad van, rosszul írtam. Úgy akartam írni, hogy initramfs crypttab nélkül, mert nem járnak együtt szükségszerűen. A crypttab már az initramfs után töltődik be bootkor.
Én mindig azt az utat jártam, hogy az egész lemez volt titkosítva (a root, swap, home, var, adatok is, kivéve a /boot). Az initramfs elindul, mkinitcpio hookjaival induló cuccok kérik be a jelszót a titkosítás feloldásához, azok is oldják fel, ezzel kinyílik az egész LUKS réteg, felette az LVM már hozzáférhető, annak minden VG-ja és LV-ja fel lesz oldva egy lépésben, mindenféle crypttab meg hasonlók nélkül. 20+ karakteres jelszóval, néha 30+ karakteressel, nem szótárazható, vegyesen mindenféle karakter, kisbetű, nagybetű, szám, írásjelek, ékezetes karakterek. A default dmcrypt cryptsetup beállításokat használtam, 256 bites aes-xts-plain64, sha256 vagy sha512 hash, 1000-2000 iteráció a kulcsfeldolgozásra. Minden bootkor vagy felcsatoláskor gépírással bekörmölve a jelszót 1-2 mp. alatt.
Viszont soha nem használtam alatta RAID-et, inkább külön titkosított lemezen tartok független backupot.
SSD-n sokkal egyszerűbb, beépített AES titkosítás, 20+ karakteres ATA jelszó (itt már van az egyik gépemen gyengeség, mivel a korai Lenovo BIOS-UEFI csak A-Z/0-9 karaktereket enged, nem lehet semmit variálni a kis/nagybetűkkel, egyéb karakterekkel). Viszont 0 terhet ró a procira (igaz már korábban sem volt gond, mert szoftveresen sem nagy teher a mai prociknak az AES256, még akkor sem, ha nincs hardveres AES-NI utasításkészlet), de I/O overheadje sincs, nem gond a TRIM sem. Plusz mivel így egy jelszóval oldódik fel az összes partíció, az összes OS-nek (teljesen transzparens), így nem kell LVM, az nálam csak szükségmegoldás volt. Kevésbé biztonságos, mint a LUKS, de ipari és nemzetbiztonsági adatokat nem őrzök, csak némi személyes doksi, meg egy kis torrentes letöltés (sorozatok, néhány film és játék). Régen volt nagyobb seed állományom is titkosítva, de ma már nem seedelek sokat, helyette előfizetős megoldásra váltottam (VIP tagság, Netflix, stb.). Arra elég, hogy jogvédők, meg hatóságok gond esetén ne másszanak bele az adataimba.
-
-
sh4d0w
félisten
válasz
Dißnäëß
#26987
üzenetére
Elkeserítelek: amikor szoftveres disk encryptiont használsz, a master password mindig a memóriában van és megfelelő csillagállás esetén kinyerhető. Másik támadási módszer lehet, ha úgy módosítják a LUKS-ért felelős forráskódot, hogy írja ki egy pendrive-ra a jelszót.
Szoftveres disk encryption esetén esetleg használhatod a Kali nuke opcióját, Google segít megtalálni.
Ha ennyire biztonságban akarod tudni az adataidat, használj hardveres titkosítású háttértárat. Ez esetben (feltehetően) csak NSA és tsa az ellenfeleid, a megfertőzött firmware-eken keresztül.
-
Frawly
veterán
válasz
Dißnäëß
#26987
üzenetére
Valószínűleg előbb akarja elérni a logikai köteteket, mint hogy a LUKS-ot fel tudta volna oldani. Azt még tudni kéne mi alatt csinálod, mert nekem ezzel csak olyan disztrókon van tapasztalatom, amelyek nem crypttabot, hanem initramfs-t használnak.
Egyébként nem értem miért akarsz titkosítást, ha nem akarsz jelszót beírni. Annak pont az lenne a lényege, hogy jelszót kelljen beírni, és jelszó nélkül más ne tudja megnyitni. Lehet elvileg, hogy valami USB drive-ról húzza be a titkosításhoz használt kulcsot, de azzal később a támadó dolgát is megkönnyíted, mert elég lesz neki azt a drive-ot megszerezni, kicsit olyasmi, mint a lábtörlő alá a kulcsot odakészíteni. Jelszónál csak a te fejedben van meg a kulcs, nem létezik fizikai könnyítés, hogy hozzá lehessen férni az adatokhoz. Tudom, kényelmetlen minden bootkor meg minden egyes felcsatoláskor jelszót bekörmölgetni, de az adatbiztonság és a kényelem kölcsönösek kizárja egymást. A crypttab sem jobb megoldás.
A random adatokkal felülírás nem kötelező, azt csak azért szokták használni, hogy ne lehessen adatmintázatok alapján a titkosítást támadni. De SSD-knél a TRIM úgyis felfedi, hogy mely szektorok nincsenek használatban, szóval ez úgyis bukó lesz, meg HDD-knél is egy idő után, mikor telepakolod titkosított adattal, egy nagy pszeudórandom adathalmaznak látszik az egész, úgyhogy nem tudnak visszakövetkeztetni adatmintázatra. Így ez a dd if=/dev/random inkább paranoia, mint a HDD több menetben legyalulása.
Én mióta SSD-ket használok, nem használok többé LUKS-t. A TRIM miatt így is, úgy is támadható lenne, meg az SSD-nek nem tesz jót, hogy dugig van adattal (TRIM nélkül úgy érzi az SSD vezérlője, hogy minden szektorban lévő adat hasznos adat, és a wear leveling ellehetetlenül). LVM-et meg csak azért használtam korábban is, hogy az összes kötetet egyszerre, egy jelszóval lehessen feloldani. Így SSD-ken a hardveres öntitkosítást használom ATA jelszóval, ez transzparens az OS-ek számára és az SSD élettartamára sincs negatív befolyással. Igaz cserébe elméletileg kevésbé biztonságos, mint a LUKS, de a gyakorlatban nem olvastam még olyanról, hogy megtörték volna. Meg az SSD hardveres öntitkosításának a másik veszélye, hogy ha elfelejted a jelszót, kizárod magad a meghajtóból és többé nem lehet leoldani róla (mert nem csak az adatok biztonságát szolgálja, hanem lopás elleni védelmet is nyújt), ki kell dobni (a gyártó, NSA sem tudja leoldani róla a jelszót, nincs kiskapu, meg backdoor). LUKS-nál csak újrahúzol mindent szoftveresen, és max. csak az adatokat bukod, ha nem volt backupod.
-
válasz
Frawly
#26986
üzenetére
Ebben azért nem vagyok biztos, hogy RAID-et ilyen könnyű lenne megnövelni, hogy egyszer egy nagyobb diskre építed újra a tömböt, aztán a másik lemezt cseréled ki nagyobbra.
pedig ezt pont lehet, igaz az én esetemben nem volt LUKS meg LVM meg egyéb nyalánkságok
-
bambano
titán
válasz
Dißnäëß
#26987
üzenetére
"Namost, hiába van titkosítás után logikailag az LVM szint,": nem értem, amiket írtok. a luks az a disk manageren használt titkosítási rendszerből egy titkosítási fajta.
tehát nincs olyan, hogy luks-lvm, két okból sem: az egyik egy blokk-eszköz menedzser, a másik meg egy titkosítási módszer.másrészt mivel dm-cryptet használ, ami az lvm része, ezért fogalmilag lehetetlen a luksot betenni az lvm alá.
tehát ha úgy használod, ahogy le van írva, akkor raid-lvm-luks-lvm a sorrend.
szerintem raid-re lvm-et kell tenni, majd az lvm-en kiosztott köteteket kell luks-szal titkosítani. ha nem akarod bootoláskor kézzel beírni a jelszót, akkor a crypttab-ba bele kell írni, és kész. mondjuk akkor rögtön semmi értelme lesz az egésznek, mert minek titkosítod, ha adod mellé a jelszót... -
Dißnäëß
nagyúr
válasz
kraftxld
#26989
üzenetére
Dehogynem, jó ötlet.. viszont szerintem a két diszkes, Intel+nVidia kombós laptopokat csak részben támogatja, ha egyáltalán.
Viccet félre, még ha dedikált NAS-t építenék is (és ez a terv egyébként), sok tanulást nem rejt magában a dolog, számomra meg fontos ez. FreeNAS-om is volt, NAS4Free-m is, OpenMediaVault-om is, de akkor még gyerekcipőben jártak, voltak bugok rendesen, vagy interfészbeli "nem mentődik el" dolgok, satöbbi, hibák itt-ott.
De ez régen volt, Neked lehet, jók ma a tapasztalataid velük.
Jók, de ilyen kész motyóban nem gondolkodom. Akkor nem tanulok. 
Ha viszont megértem egy Debiannal az alapokat, kicsit mélyebbre túrok a témában, mind a laptopom, mind a házi/kis-irodai NAS-omhoz van/lesz tudásom, hogy mit, hogy, merre. A szívást meg vállalom. Igazából elég nagy súllyal szól erről is a dolog (tanulás), nem csak a végeredményről. -
Dißnäëß
nagyúr
válasz
Frawly
#26986
üzenetére
Az első bekezdésedet nem biztos, hogy értem. Emlékeim szerint tutorial-ból már vagy pf, 3-4 éve (?) lenyomtam egy ilyet hibamentesen, élesben: a 3x2TB WD Green raid5-ömről másztam át (ja, elég életveszélyes üzemmódban)
az új, 3x4TB Seagate NAS HDD vinyóimra. Túléltük. Mondjuk tényleges adatom volt sok rajta, de "bukható", semmi critical.Azóta meg már hol vannak ezek..
Eladogattam. Zúgott. -
Dißnäëß
nagyúr
válasz
Frawly
#26986
üzenetére
Az LVM hasonló megoldásáról még csak nem is olvastam, vagy nem mesélt senki. Ha pár szóban elmondod, megköszönöm.
Nem ragaszkodom hardcore módon a raid-hez, csak egyelőre nem nagyon volt más a fejemben, persze, nézegettem CUPS-ot, meg sync dolgokat, alternatívákat, amik félig vagy egyáltalán nem on-the-fly és más szinteken is dolgoznak, de ott még nem járok fejben sem.-------------------------------
Az említett Raid-LUKS-LVM-fájlrendszer topológiát lemodelleztem-kipróbáltam, szuperül működik, egyetlen dolog zavar: boot-oláskor ugye meg kell adni a titkosított kötet(ek) feloldásához a jelszót.Namost, hiába van titkosítás után logikailag az LVM szint, már a jelszó bekérése előtt jelez - esetemben - két hibát a rendszer, hogy ez és ez a logical volume nem található, fallback-el autodetection-re.
Még ez sem lenne gond, mert a jelszó megadás után ahogy a diszkek feloldva, az autodetect miatt azonnal beugranak a logical volume-ok és megszűnik a jelenség, csak inkább esztétikailag zavaró, hogy mondjuk az egyik lv-met elnevezem "robi"-nak, másikat elnevezem "kakaoscsiga"-nak és még a titkosítás feloldása és a teljes rendszer indulása előtt máris dob a gép két olyat, hogy robi és kakaoscsiga nem található...
Működni működik a megoldás, de - nem tudom, ez csak Debian sajátosság-e - ez így direkt így megírva, vagy így meghagyva, nekem privátszféra szempontból ilyen szemtikkelős. Oké, senkinek nem jelent semmit ez a kis infó, hogy robi és kakaoscsiga (azon kívül, hogy ha tud magyarul, vagy beüti gugliba, rájön, hogy ez egy magyar ember elhagyott laptopja a tengerparton) .. na .. értitek
Azt vártam, hogy míg a LUKS kódokat nem adom meg a diszkek feloldásához, ember meg nem mondja (még a /boot tartalmából sem), hogy ki-mi fia-borja lakik bent a gépen. Annyit lát, hogy valami linux, van egy látható /boot-ja és egy nagy titkosított partíció, jónapot. Az meg egy NSA-t úgysem állít meg, de én nem is ilyen szintre törekszem, hanem csak alap szinten védeni a laptopot mondjuk, ha elhagyom. Úgysem áll neki törni, leparticionálja és kész, de legalább az infó nem megy ki a gépről.
--------------------------------
Hab a tortán, hogy hiába törlöm a LUKS header-t mondjuk kézzel, kitéve egy USB live linux-os boot diszk-re, VAGY neadjisten a teljes /boot -ot egy kis nyakamban lógó USB-re telepítem (és ezt lehetne még ragozni), mivel a raid a legalsó szint, nem csak annyi látszik a HDD/SSD-ből, hogy random adat, vagy van rajta valami, vagy nincs, hanem konkrétan elég gyorsan megmondható még header törlés után is, hogy ahhhaaa, itt superblock-ok vannak, ez egy vagy üres, de inkább titkosított raid meghajtó amúgy. Egy használatban lévő rendszeren meg egy --zero-superblock-ot meg nem zavarnék végig nyilván.Innentől persze ha nem az említett hárombetűs szerv, nem jut tovább senki, csak szintén érdekességként dobom fel, hogy bár logikailag marha jónak tűnik az, amit mondtatok és én is elfogadtam a RAID-LUKS-LVM-fájlrendszer sorrendet, a gyakorlatban szívem szerint a LUKS-ot tenném legalulra. De ez csak megérzés és nem biztos, hogy a legtökéletesebb megoldás
Csináltam már így régen, még zöldebb fűlűbbként
, ment is, csak raid5 esetében kényelmetlen volt egyszerre 3 diszket feloldani indításkor. Viszont az LV-k hiányára ott is ugyanúgy figyelmeztetett, nevén nevezve őket 
aztán fallback autodetect-re és mikor feloldottam mindent és raid is beugrott, összekaparta magát azonnal az LVM is és hibátlanul felállt a rendszer.------------------------------------
Ahogy olvasgatok itt titkosításról és tényleg, tökéletesen random-nak tűnő adatról egy adott gép HDD/SSD-jén, úgy látom, már ez is kisebb malőrökbe ütközik, pötyögni kell rendesen hozzá, nem annyi, hogy a mezei user-nek felajánlja egy Ubuntu telepítő, hogy na akkor titkosítsunk és über safety-ben vagy, kedves user.Már a technikai megvalósítás is fejvakarós. Összerakható, csak fejvakarós. És akkor ez még csak a technikai szint, hogy full-tökrandom adatnak tűnik a háttértár tartalma, ember és program és AI meg nem mondja, mi van rajta. A humán faktor még hátravan
De a deniable encryption, steganography és hasonló megoldások már nem érdekelnek
Tehát a földön maradva, ezek az LVM hibaüzenetek "furák", hogy titkosítás-feloldás előttre betolja a rendszer. Egy 9.5-ös Debiltől mást várnék már defaultban is, de gondolom, ez technikai akadályokba ütközik, azért ilyen.
-
Frawly
veterán
válasz
Dißnäëß
#26984
üzenetére
Ebben azért nem vagyok biztos, hogy RAID-et ilyen könnyű lenne megnövelni, hogy egyszer egy nagyobb diskre építed újra a tömböt, aztán a másik lemezt cseréled ki nagyobbra.
A többi viszont úgy van, ahogy írod, meg a sorrend is, ahogy feletted írta a kolléga. Az világos, ha ragaszkodsz a RAID-hez (mert nem felel meg az LVM hasonló megoldása), annak kell lennie a legalsó szintnek, az alatt nem lehet semmi. A legfelsőnek meg a fájlrendszer. Közötte lehet variálni, hogy alul LUKS, felül LVM, vagy fordítva, de úgy a legjobb, ahogy írták, hogy a LUKS legyen alul, így egy LUKS feloldással az összes logikai kötetet és fájlrendszert fel lehet oldani. A fordítottját azoknak találták ki, akik nem minden logikai kötetet akarnak titkosítani, de gondolom nálad nem a helyzet, de az összeset akarod. Volume group-ból elég egy.
RAID-et még nem méreteztem át, LUKS-ot sem. LVM-et, fájlrendszert viszont könnyű átméretezni.
-
Dißnäëß
nagyúr
válasz
sh4d0w
#26981
üzenetére
Ez a sorrend aranyat ér, köszi. Bevésem agyba.
Végülis logikus: először felépítek egy raid5(6) tömböt, redundancia adott, ha 1(2) vinyó elszáll. Efelett a LUKS még semmit nem érez mindebből, logikailag egybe lát mindent, efelett meg LVM-ben tudom a "partíciókat" úgy tilitolozni és méretezgetni a teljes kapacitáson belül, ahogy akarom.
Magyarul ha 3x1TB példánál maradunk, egy bővítés menete később így nézne ki:
- 1. HDD csere nagyobbra.
- raid tömb degraded-ből újraépül teljessé (mdadm mókolás, megoldom)
- 2. hdd csere nagyobbra
- raid tömb degraded-ből újraépül teljessé (még mindig 2TB-n maradva összkapacitásban)
- 3. hdd csere nagyobbra
- raid tömb degraded-ből újraépül teljessé (még mindig 2TB-n maradva összkapacitásban)
- raid tömb resize 2TB-ról nagyobbra (luks efelett ezt hogy kezelné vajon, hogy bővült az alatta lévő réteg?)
- LUKS titkosítás kiterjesztése az új, nagyobb méretre (?)
- LVM volume group 1 lesz, ennek bővítése (?)
- egyes LVM volume-ok bővítése az új méretreKb ?
-
Dißnäëß
nagyúr
Igen, ez vili, lehet így bevonom a negyediket is, a 4TB-sből egy 1 terás szeletet.
VM-ben már csináltam teszt jelleggel akkora kreténséget, hogy 3 diszkes raid5-nek egyik lába SSD volt. Működött éppen, bár akkor még úgy tudom, nem tudta a kernel az on-the-fly trim-et, 3.x verzió elején (mármint trim (discard) softraid esetén). Ma már viszi, azt gugliztam nemrég. Bár ez most még HDD raid lesz, nem téma a discard. Tudom, LUKS+SSD+discard odafigyelést igényel, de ez nem az enesa, és nem is ssd most. -
sh4d0w
félisten
válasz
Dißnäëß
#26978
üzenetére
RAID - LUKS - LVM - filesystem.
LUKS az LVM felett felidézheti a sajtreszelős emlékeket. Meg lehet ugyan csinálni, de komplett adatvesztéssel jár - ezért is erősen javasolt telepítéskor LUKS-ozni.
DE: nagyon oda kell figyelni, ha új diszket teszel be. Elég egyszer rossz sorrendben kiadni a parancsokat és mindened oda lehet egy pillanat alatt. Állandóan látnod kell a fejedben a logikai felépítést és teljesen biztos tudással kell rendelkezned az utasítások megfelelő sorrendjéről.
-
letix
senior tag
válasz
Dißnäëß
#26978
üzenetére
Szia,
Egész jól összeírtad az igényeidet, azt hiszem ebből már lehet építkezni..
Nem vagyok a témában nagy spíler, de tudomásom szerint az LVM tud RAID-et kezelni anélkül, hogy te mdadm-al is építkeznél rá. Tehát szerintem a kettő együtt fölösleges lehet.
[link]
Egyébiránt pedig én lehet hogy kicsit játszadoznék a témával virtuális környezetben. Egy Debian telepítő expert módban szépen össze tudja tenni titkosítva és LVM-el a dolgokat különösebb hozzáértés megléte nélkül, ezt követően pedig már tudod tesztelgetni, bővíteni, stb..udv
letix -
Dißnäëß
nagyúr
Sziasztok,
gondoltam, ide írom, nem a kezdőbe, hátha Tudtok pár építő jellegű tanácsot adni.
Adott:
- 3x 1TB 2.5" HDD
- 1x 4TB Seagate NAS HDDSoftraid, Debian.
Még nincs telepítve semmi, bare metal egyelőre![;]](//cdn.rios.hu/dl/s/v1.gif)
Per pillanat desktop üzemmód, polcon szétszórva, külső USB dokkolóban, melyik hol merre és mikor hogy használva, teljes káosz a könyvtáraimban, stb.Tegnap 1 órámba telt papíron összerakni valami rendszert arra, hogy mit hol szeretnék tárolni
és minek mennyi a
- 1) minimum redundancia
- 2) tárhely
igénye.Megszültem.
Atyaég .. 
Ekkor merült fel bennem a kérdés, amit ide is hozok most: hogyan oldanátok meg egy dinamikusan méretezhető, titkosított softraid tömbözéses megoldást ?
Alap dolgokra kell gondolni most nálam, nem kell agyonszofisztikálni se a titkosítás, se a redundancia oldalát, passzív adatvédelemre gondolok, nem UPS-es, akksikkal és dedikált raid kontrollerekkel megtámogatott hotplug loadbalancing-os HA setup-ra. Otthon vagyunk, a spájzban.
, de azért többet hoznék ki belőle, mint a Windows-om és a notis Debianom, amit most nyújt.Hardverek adottak, így kicsiben indulva ezt tenném:
- 3x 1TB kis HDD -> raid5, 2TB
- 1x 4TB nagy HDD -> Önállóan hagyni
- LUKS titkosítás (ha ellopnák a dobozt) minden HDD-n
- LVM ha a fájlrendszerbe felmount-olt "könyvtárakat" növelni szeretném, ha nagyobb diszkekre állok pl. 2 év múlva.
- nem fájna +1 kis HDD és akkor raid6-ozás, ez ha 1 kihullik és rebuild van, még mindig redundáns a tömb. De a kérdésem fókusza most nem ez elsősorban.Gondolom itt a kulcs az LVM. Ilyet viszont nem nagyon csináltam még, úgyhogy nézzétek el a hülye kérdéseimet
1. Legelőször titkosítanátok az egyes lemezeket, majd a titkosított logikai diszkeket boot idejű feloldás után raid tömbbe rendelni és a raid tömböt LVM-ezni ?
2. Vagy először LVM, arra raid, a legtetejére egy LUKS, ami az egész logikai izét letitkosítja ?
3. Egyéb sorrend ? (Gyanítom, ez lesz ..)
A lényeg a flexibilitáson van számomra, szóval ha holnap hozok a 3x1TB helyére 3x2TB-t, akkor szépen fokozatosan 1-enként cserélve őket fel tudjam pár konzol parancs és óra/nap után hízlalni a raid tömbömet 2TB-ról 4TB-ra úgy, hogy ismét (azaz továbbra is) titkosítottan kerül minden a HDD-kre.
Igényem az is, hogy JBOD módban a 4 terás "hullható" HDD mellé vett 2 terásat hozzácsapom és növelem a logical volume méretét, reboot, kész, hátradől. (Természetesen ez is titkosítva, tehát minden diszk titkosítva).
Ezt a jellegű flexibilitást milyen setup adja meg nekem ?
Azt szeretném megérteni, hogy a LUKS-LVM-RAID megoldásokból milyen réteg van legalul, mi azon, és mi legfelül, hogy nagyon egyszerű és nagyon könnyű legyen az átméretezése, "hízlalása" a kipublikált tárhelyemnek.
Még a JBOD-t se feltétlen erőltetném, mert ha 1 hullik, minden hullik.. lehet bemount-olom a 4 teráson lévő partíciót simán valahova a könyvtárszerkezetbe és jónapot, többi önálló "kieshető" vinyót dettó, ha lenne.
-
kraftxld
félisten
Red Hat (nem RHEL) 9 fut egy Hyper-V 2016 szerveren.
Nincs rajta a hyper-v integration components telepítve, de hirtelen csak RHEL verziókat találtam.
Erre van valami megoldás, hogy menjen az integration components és ne a béna legacy hálókártyát kelljen használni? -
#26976
Friczy
senior tag
MasterMark
#26974
Friczy
senior tag
válasz
MasterMark
#26974
üzenetére
Akkor böngéssz leírást, állítsd be a konfig file szerkesztésével, a webmint meg felejtsd el. Más esetben is. Lyukas, mint a szita, nem véletlenül hajították ki a standard Debianból.
-
bucihost
senior tag
Sziasztok!
Adott egy deb 9 x64-es szerver. VESTACP-t használok rajta. a webes rész tökéletes benne. Viszont most úgy alakult, hogy az email részét is használnom kellene. Viszont itt meghasal a történet. Hiába vannak beállítva a dns rekordok (SPF, DMARC, DKIM), csomó levelezőre nem mennek át a levelek. Futtattam rajta több mail szerver teszt oldalt is, mind vissza dobja hogy a fenti rekordok nem találhatóak. Netet bújva kiderült, hogy ez csomó VESTACP usernél elő jött.
A kérdésem az lenne, hogy ismeri-e valaki a VCP-t, és tudja-e mi lehet a megoldás, vagy van e valami más free alternatíva a VCP helyett ami működhet?
Köszi előre is
-
#26974
MasterMark
titán
letix
#26973
-
#26973
letix
senior tag
MasterMark
#26971
letix
senior tag
válasz
MasterMark
#26971
üzenetére
Szerintem forwarder nélkül a 1x db root szervet kérdezgeti a bind-od.
Azt nem nagyon értem mit jelent hogy a root-nak saját magát adtad meg. A root alatt szerintem te mást értesz mint ami.udv
letix -
#26972
bambano
titán
MasterMark
#26971
bambano
titán
válasz
MasterMark
#26971
üzenetére
"Root szervernek saját magát adtam meg.": azt tudod, hogy hol kell megadni?
-
#26971
MasterMark
titán
bambano
#26970
MasterMark
titán
válasz
bambano
#26970
üzenetére
Ezt nem értem.
Csak belső DNS szervernek kell, nincs internetre kirakva. Saját domain-ra ő oldja fel, minden mást meg forwardoljon. Ez lenne az alapötlet.
De mikor beállítottam a címeket, akkor tesztelés közben már tudott feloldalni mást is, nem csak azt ami az én domain-om. Forwarder még nem volt beállítva.
letix: Root szervernek saját magát adtam meg.
szerk.: Esetleg egy DNS-over-TLS-t jó lenne megoldani rá, meg egy reklámszűrős blokkolást. (Mármint csak a forwardra, nyilván belső hálón nem kell.)
-
#26970
bambano
titán
MasterMark
#26968
bambano
titán
válasz
MasterMark
#26968
üzenetére
teljes rezolvernek nem kell forwarder.
szerk: arra viszont vigyázz, hogy csak annak a címtartománynak rezolváljon, ami a belső hálózatod, mert ha nem, abból csúnya ddosok lehetnek.
-
#26969
letix
senior tag
MasterMark
#26968
letix
senior tag
válasz
MasterMark
#26968
üzenetére
Nem értek a lovakhoz, de nem lehet hogy a root szervereket azért megkérdezi?
udv
letix -
#26968
MasterMark
titán
MasterMark
titán
Üdv, csináltam egy BIND szervert, viszont nem állítottam be forwardert, akkor is tudott válaszolni netes dns keresésre. Ez mitől van?
-
-
Frawly
veterán
Annak elvileg normálisan kéne mennie akármilyen disztró alatt, az alap, kernelben lévő amdgpu modesetting driverrel, 3D-ben meg csak a mesa csomag kell neki, semmilyen zárt drivert, meg trükközést nem igényel.
Azt hiszem gyurmafigurának (Bob) ilyesmi kártyája van, ő tud segíteni ebben az ügyben.
-
Vladi
nagyúr
-
Volkov
senior tag
Sziasztok!
Remélem elfér itt a gondom, talán nem full kezdő kérdés.
Adott egy Gigabyte Brix GB-BACE-3160-as barbone gép, melyen Ubuntu 16.04.2 LTS fut (gui nincs).
A gép rá van kötve a TV-re HDMI-n keresztül, és Kodi fut rajta non-stop.A gond a következő: az utóbbi időben sokszor volt 1-1 percre áramszünet itthon. Ilyenkor a gép természetesen újraindul, aminek a következménye, hogy nincs kép. Mivel a Brix el van rejtve, ilyenkor be kell ssh-zni, és bekapcsolt TV-vel reboot, hogy visszajöjjön a kép.
Kérdésem: hogyan lehet force-olni, hogy milyen kimeneten és milyen felbontásban küldje a képet?
Amit eddig próbáltam:
1. xrandr-el felbontást állítani, de amíg nem megy a TV, ez elhasal, mert nem talál aktív monitort. Ha már megy a TV, akkor már vissza lehet hozni xrandr-al, de nem vagyok előrébb mint a reboot-tal.
2.Bekapcsolt TV-nél lementettem az edid-t, majd csináltam két plusz config file-t /usr/share/X11/xorg.conf.d/ alá, 10-monitor.conf és 20-intel.conf.
Az intel.conf-ban megadtam neki, hogy a custom lementett edid-t használja (x log alapján ez meg is történik) majd a monitor.conf-ban (elvileg) fix-re állítottam a felbontást, de nem működik a dolog, kikapcsolt TV melletti boot után nincs kép.10-monitor.conf:
Section "Monitor"
Identifier "HDMI3"
ModeLine "1920x1080_60.00" 148.800 1920 2008 2052 2185 1080 1084 1089 1135 +hsync +vsync
Option "Enable" "true"
EndSection
Section "Screen"
Identifier "LGTV"
Device "card0"
Monitor "HDMI3"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1920x1080_60.00"
EndSubSection
EndSection
20-intel.conf:
Section "Device"
Driver "intel"
Identifier "card0"
Option "CustomEDID" "HDMI3:/home/kodi/edid.bin"
Option "IgnoreEDID" "false"
Option "UseEDID" "true"
EndSectionTud valaki segíteni?
Köszönöm előre is! -
#26958
King Unique
titán
#61392896
#26953
King Unique
titán
válasz
#61392896
#26953
üzenetére
Mi az, hogy úgy marad fél napig? Ilyenkor, ha még használja valami, akkor normál esetben ki szokta írni a leválasztásnál, hogy a kötet foglalt. Terminálban az
udisksctlilyenkor működik, vagy azt nem is próbáltad? Az utóbbi azunmount+power-offparancsokkal amúgy teljes leválasztást csinál, nem szimplán csak a kötetet csatolja le. Ha 2,5"-os külső HDD-t használsz, annál pont hasznos is, mert ezáltal rendesen leáll az eszköz és benne a merevlemez, nem működés közben rántod ki alóla a tápot a kábel kihúzásával. De rendszerint grafikus felületen is megoldható ugyanez a megfelelő leválasztási opcióval. -
Frawly
veterán
válasz
#61392896
#26953
üzenetére
Valószínű azért nem tudod leválasztani, mert valamelyik folyamat használja a felírás után is. Próbáld egyesével bezárni a futó progikat, és minden egyes bezárt alkalmazás után megpróbálni a kiadást. Ha akkor sem veszi be, akkor előszeded a terminált és elkezded gépelgetni azokat a parancsokat, amit írtak, sync, ha ezután sem adja ki, akkor dmesg.
Esetleg ha már sehogy nem engedi kiadni, akkor se húzd ki, ideiglenes megoldásként indítsd újra a gépet. Úgy biztosan szabályosan leválasztja, és nem lesz gond a fájlrendszerrel.
-
#61392896
törölt tag
válasz
Frawly
#26948
üzenetére
Nem viccből. És a válasz sem oldotta meg a problémát. Hiába kérem a kiadást, úgymarad akár fél napig is. Nemérdekes. Már másképpen oldom meg a dolgot. Külső winyóval viszem. Ha annál kérek kiadást, az megcsinálja egyből. Pedig elviekben lassabb mint a pendrájvom. Szóval haladó vagy nem, amit kérdeztem, arra eddig nincsen redes megoldás. Valószínűleg egy rendszerhiba.
-
Frawly
veterán
válasz
Rimuru
#26949
üzenetére
Ilyenről nem tudok. Alapértelmezetten az eltávolítható meghajtók gyorsítótárazása szokott lenni beállítva. De nem győzöm hangsúlyozni, hogy nem csak a cache a baj ilyenkor, mert ha ki is írja a meghajtóra fizikailag az adatokat, és kihúzod az OS alól, nem csatolja le a fájlrendszert, és az is gondot okoz egymagában. Ezt még tizensok éve én is megszoptam néhányszor, hogy pendrive-ra, meg USB mass storage-ös mp3 lejátszóra fájlokat küldtem XP-s gépen, de mivel siettem, csak úgy kihúztam leválasztás nélkül, és gond volt belőle, nem látszottak a ráírt fájlok, pedig a cache biztosan kiíródott rá. Tudtam, hogy hülyeséget csinálok, nem javallott, de úgy voltam vele, hátha 1-2× belefér. Nem fér bele. Azóta mindegy mennyire sietős, mindig leválasztom, ezt a lépést semmi esetre sem szabad lespórolni, beáldozni a biztonságot a sebesség vagy a kényelem érdekében. Ez egy annyira alap dolog, mint hogy konnektorból sem huzigáljuk ki a gépet menet közben.
De ugyanez pepitában, mikor kezdőbb userek azzal szívnak, hogy a Win10 a fast boot miatt default csak félhibernálós állapotba áll le, utána betöltik dual bootban a Linuxot, és csodálkoznak, hogy miért írogat hibát a korábban le nem csatolt NTFS fájlrendszerre. Ebben az esetben sem az a gond, hogy nem sync-elődött ki a cache a tartalma, hanem hogy nem lett lecsatolva a fájlrendszer. A fájlrendszer le nem csatolása csak akkor megy el, ha csak read onlyként volt felcsatolva, de még ilyenkor sem javallott leválasztás nélkül lehuzigálni, a futó rendszeren okozhat anomáliákat. Tudom, ezt elég morbid haladó topikban magyarázni, mert az ilyen alap dolgok errefelé mindenkinek triviálisak, de hát ha itt jött elő, akkor jobbnak láttam kicsit mélyebben tisztázni.
-
Frawly
veterán
válasz
#61392896
#26921
üzenetére
Ezt ugye csak viccből kérdezted? Pláne a haladós topikban. Ezt még a legkezdőbb windowsos ECDL Mancikák is tudják, hogy pendrive-ot csak úgy nem húzogatunk ki semmilyen OS alól, le kell előtte választani Windows, Linux, FranctudjamilyenBSD meg MacOS alatt is. Még akkor sem szabad kihúzni, ha már a visszajelző ledje nem villog, és ténylegesen rámásolt a rendszer mindent, mert a fájlrendszer még akkor sem lesz lezárva. Egyébként meg ha már véletlenül kihúztad, és hiba keletkezik a fájlrendszeren, akkor sem kell újraformázni, Win alatt chkdsk kötet: /f parancsot kell ráküldeni, Linux alatt az ntfsfix /dev/sdb1-et kell ráküldeni (lehet nálad más az eszközjele), nem kell mindig újraformázni.
(#26930) Lenry: ugyanezeket tudja a sima dd is, ha conv=fsync status=progress paraméterekkel hívod meg. Nem hallottam amúgy még erről a dcfldd-ről, lehet végül is van olyan szolgáltatása, ami a sima dd-ben nincs meg. A sync parancsot meg elég csak egyszer kiadni.
-
#26946
#61392896
törölt tag
King Unique
#26927
#61392896
törölt tag
válasz
King Unique
#26927
üzenetére
-
Vladi
nagyúr
válasz
Dißnäëß
#26941
üzenetére
Én szétválasztanám 3 részre a dolgot.
1. induló cégbe olcsó, gyors megoldást betennél, mennyen.
2. magadnak otthon tanulás céljából lehet flexelni, meg élhajlítani házat, meg árpi klasztert építeni.
3. hagyni az első kettőt a francba, inkább a cégre koncentrálni.
3/a: ha jól megy, akkor sok melód leszvele.
3/b: he nem megy jól, akkor sok melód lesz vele. -
bambano
titán
válasz
Dißnäëß
#26941
üzenetére
pár felhasználós cég irodáját kérdezted, nem az enterprise űrhajó parancsnoki hídját.
pár felhasználós céghez kitesz az ember egy microservert, oszt jónapot. polcon legyen tartalék, bedöglik, tartalék kivisz, diszk átrak, go.ha te clustert akarsz építeni meg tanulni, akkor azt kell megkérdezni.
egyébként én nem csinálnék inkrementál backupot, ha realtime-t is lehet.
-
Dißnäëß
nagyúr
válasz
bambano
#26940
üzenetére
Szerintem hunyorítok és a gombok is tetszenek.
Ha jó a mini HA-jellegű setup, ha nem is széjjel szofisztikálva táppal stb, de pl. ha 1 gép komplett kidől, csak vállvonás, szóval dzsunka is lehet, a microserver overkill. Azaz nem az, csak szeretném megtanulni tényleg ezeket a totál automatikusan deploy-olt cluster alapokat.Nem élő cégről van szó, de kb. fél év múlva az lesz (a sajátom), egy kis szolíd iroda pár alkalmazottal, cimbimmel ketten csináljuk, szóval arra költünk, amire akarunk. Én meg egy ideje Debian-t túrok hobbiból, de gondoltam bekérdezek itt olyat, aki hardcore-abb nálam (nem nehéz ilyet találni sztem)
és otthon van ezekben a kérdésekben.Mivel (audio) erősítőt is építgetek hobbiból, amihez rengeteg alumínium házat láttam már aliexpress-en, azon agyalok, hogy simán összehozok egy rakás mini ITX lapot slim hűtővel kisfogyis procival egyetlen ilyen házba, élükre állítva, táp, föld, minden nyavalya úgy megoldva, hogy hát .. ja .. DIY szerver.. előlapon 2x12cm venti telibe, alacsony fordulaton, Arduino környezeti hőmérséklet monitorozás és relével tápok ki-be kapcsolása ha para van, .. szóval .. igazából ja, a "dzsunka" nekem tök jó.
Az AMD jó tipp
, nem kell ide nagy power sztem és olcsóbban kijövök belőle, azt látom így egy villámgyors gugli után.Diszkek: sztem lenne vagy 3x4TB NAS HDD backup célból egy külön NAS-on, az egyes gépekhez meg simán egy szolíd SSD és kész, mint local storage. Meg a Victor Hugo-ba vagy ekvivalensbe beteszünk egy dedikált vasat (dzsunka2, 3xHDD), amire minden hajnalban átmegy egy incremental backup .. valami .. ilyesmi .. így most elsőre.. fejben .. nagyon távolról "megszakértve"
-
bambano
titán
válasz
Dißnäëß
#26938
üzenetére
szerintem nem kell ezt túlgondolni. a rakás pi az rossz ötlet, mert egyrészt nincs rajta diszk csatoló, másrészt úgyis a diszkek viszik el a fogyasztás jelentős részét, ami minden választás esetén ugyanaz.
szóval három utat látok:
1. veszel hp microserver gen10-et. ebből van kétmagos amd apu-s is, annak az ára viszonylag baráti, meg van négy magos is, azt ha ügyesen megrázod, lehet, kipottyan belőle egy aranyrudacska.
2. ha kevés az apu, de sok pénzt akarnak vasra költeni, akkor vehetsz miniITX-es készre szerelt intel szervert. (hmm. ez most nincs kint a cég weblapján...)
3. összeraksz alkatrészekből egy kis hunyorítással szervernek látszó tárgyat, olyan procival, annyi rammal, amennyi neked tetszik.a legtriviálisabb az első. a harmadikhoz össze lehet szedni olyan konfigot, ami mindent tud, amit egy rendes szerver (távmenedzselhető, stb.), de nem szerver árban, hanem "ahhoz" képest gombokért.
szerk: ha ilyen elborult ötletet akarsz, mint a szerkesztett hsz-ben, akkor ezt is nézd meg:
dual alix apu.dual mitx házakat a mini-itx-en találsz.
-
Dißnäëß
nagyúr
Sziasztok (ismét)
Továbbra is tanulási céllal: Ti milyen megoldást ajánlanátok egy mai pár felhasználós cég, iroda, stb. infrastruktúrájának a back-end-jéhez ? Nem szeretnék cloud-ozni, ehelyett inkább arra gondoltam, hogy valami Ubuntu Server Maas-os dolgot (Metal as a service) ki lehetne próbálni és ezen keresztül telepíteni és használatba venni az egyes szervereket.
Kérdés: irodai felhasználáshoz, tehát helyi levelezés, tűzfal, backup, kis adatbázis esetleg, ilyesmik, de semmi nagy hardcore cucc, milyen hardver ma a legjobb energiahatékonyság mutatójú ? Ami mondjuk még 100%-ban kompatibilis is az Ubuntuval és a rá teendő programokkal.
Hirtelen valami "élére állítva beteszek 10db Raspberry Pi-t egy 2 Unit-os házba" hülyeség villan homloklebenyembe, de nyilván szofisztikált megoldást keresek, amin megfelelő külső switch-el van load balancer / HA, automatikus provisioning (menet közben kihúzom a szék egyik lábát, a szék nem dől el, visszadugok egy új gépet, feltelepül és aktiválódik), ilyesmik.
Szóval valami szuperhatékony mini-motyó érdekelne, amihez nem kell nagy zümmögés, elvan a sarokban is egy viszonylag kevés négyzetméteren az egész motyó (mondjuk egyetlen egy derékig érő kisebb rack szekrényben) és kész, jónapot.
Vmi ARM lesz, vagy x86/64 ? Esetleg konkrét ajánlás ? Fogyasztás fontos, ne zabálja le a gatyánkat, teljesítmény nem: nem mining clustert tervezek
hanem mint említettem, legyen egy Exchange(-alternatíva), squid, vpn szerver, storage szerver, ilyesmik, melyikre mennyi SATA SSD-t vagy HDD-t kötök.Igen, lehetne az is, hogy mindössze 2-3 sokmagos, sok RAM-os, nagy storage-os vasat beállítok egy klassz VMWare alapú HA clusterbe és ezen virtualizálva minden istennyilát megoldok VM-eken, de most direkt nem ezt szeretném, hanem picike, kicsi, csendes, maximum kézmeleg (akár passzív is!) mini-kütyükön egy irtó energiahatékony, mégis a célnak szépen megfelelő kis setup-ot összehozni.
Tehát MAAS. De nekem az is jó, ha ezt a képzeletbeli 10db Raspberry Pi-t (vagy ekvivalens mini-alaplapot) egyetlen (!) classic álló számgépházba behegesztjük, 2 táp, 2 szünetmentes (ebből is valami alap, semmi nagy durr) és jónapot, mehet a sarokba és a villanyszámlára sincs gondunk, miközben egy mittomén, 100 fős céget kiszolgál a "géppark".
Remélem érthetően mondtam el. Inkább hardware jellegű a kérdésem, most itthon VirtualBox alatt szórakozok egy Ubuntu Server Maas Region Controller és Rack controller setup-al, meglátjuk, mi lesz belőle.
Vagy valami mini ITX ? Létezik olyan saccra 4-unit-os ház, amiben elfér mondjuk 10db Slim miniITX-es lapka (a megfelelő méretek betartásával) egymás mellett ? Vagy 10-20 Intel NUC alaplap, jó közel egymáshoz. Vagy valami Asus VivoMini miniPC jellegű pici alaplap (soDimm RAM-okkal) megoldás .. ?
Egyéb ötlet marha energiahatékony, olcsó, de várhatóan egész jó motyókra ilyen közepes-low computing power, energiahatékony célra ?
-
válasz
bambano
#26931
üzenetére
senki által nem ismert okból
erről a Magic - More magic kapcsoló sztorija jut eszembe, gondolom ismered... -
#61392896
törölt tag
Sziasztok!
Van egy problémám. Pendrájvon viszek filmeket a tévémre megnézni. Amikor felveszem, és kész, még nincsen kész. Még percekig ír fel. Bosszantó, mert ha előbb húznám ki a pendrájvot, tönkremegy az NTFS fájl-rendszer, formázhatom az egészet. Csakhogy nem mindegyik pendrájvomnak van kontrol-ledje. Segítenétek?
-
#68216320
törölt tag
Van egy olyan gondom, hogy régen egy szerveren megcsináltam a glassfish-t autostart-ra.
Gyakorlatilag meghívtam a zip-ből kitömörített könyvtárában az asadmin nevű script-et.
Namost megy is rendben, csak indőközben elfelejtettem, hogy hogyan csináltam és most jó lenne kikapcsolni az autostart-ot.
Hol lehet ilyen script? init.d, rc.local ellenőrizve, oda nem raktam. Van ötlet merre kereshetném még? -
OddMan
őstag
Transmission-t kezdtem el használni pár napja uTorrent helyett. Átnyálaztam pár leírást a neten és beállítottam a watch mappát, ami szépen működik is, ha beleteszek egy .torrent fájlt, akkor az adott torrent elkezd letöltődni. Amit viszont nem tudtam beállítani, hogyha ebből a mappából kitörlök egy .torrent fájlt, akkor az az adott torrent törlödjön az adatokkal együtt. rTorrent-nél simán működött ez a megoldás. Transmission-nél, hogyan kell ezt beállítani?
-
anorche1
őstag
Sziasztok!
Probakent par napja lecsereltem a dell e6440 gepemen manjarora a win10 -et.
Szinte mindennel elegedett vagyok, egy dolog zavar igazan: a laptop hangszoroja halkabb lett, es sokkal rosszabb minosegu. Win alatt a gyari driverrel a gep jol szolt, siman helyetessitett egy bluetooth -os hangszorot. Linux alatt viszont nagyon durvan doboz hangja van, rossz hallgatni.Ezzel nem lehetne valamit kezdeni?
-
-Ben-
veterán
válasz
Frawly
#26914
üzenetére
Fedorát próbáltam. Szinte teljesen ugyanazt produkálta, amit az ubuntu 18.04...
„Egyébként az Arch Wiki azt írja, hogy GT6xx és felette a legújabb zárt NV driver kell, tehát nem a 390-es, nem a 340-es, hanem a legeslegújabb, ami a legmodernebb kártyákhoz való.”
Most a legújabbal (396) használom, de nem javított rajta, sőt...
-
Frawly
veterán
Mielőtt kidobod azt a GT710-et, nézd meg Arch, vagy Manjaro vagy Fedora alatt. 2017-es ubis fórumokon azt olvasom, hogy ezt a kártyát jó néhány ember sikerrel hajtotta nvidia noveau kernel driverrel (ehhez nem kell semmi mást feltenni, csak a mesa csomagot a 3D-hez), meg a 340.1.4-es zárt driverrel, mindenféle gond nélkül.
Egyébként az Arch Wiki azt írja, hogy GT6xx és felette a legújabb zárt NV driver kell, tehát nem a 390-es, nem a 340-es, hanem a legeslegújabb, ami a legmodernebb kártyákhoz való.
-
-
-Ben-
veterán
A firefox, a chromium, a gnome-shell és a /usr/lib/xorg/Xorg tépi a processzort. Ablakmozgatásnál meg főleg...
Szerk.: Az Xfce tényleg sokkal jobb, mint a Gnome, de görgetésnél az se az igazi. Erőteljesen mosódik a tartalom. Összességében még mindig a KDE a legjobb, de böngészni, videót/filmet nézni egyikkel se lehet normálisan.
-
Vladi
nagyúr
"setleg van valami, amire kiemelten érdemes figyelni?"
Ablakmozgatásnál nézd meg, hogy a processzort felpörgeti -e. Esetleg videó lejátszásnál. Ez nagyon gyakori hiba új gpu-nál, hogy nem a legjobb a driver, ha annak nem megy, akkor cpu-ból próbálja megoldani.
Ami még segít, ha kicsi erőforrás igényű ablakkezelőt használsz. pl: xfce
396-os a legújabb driver, biztos, hogy támogatja. Amíg megérkezik a repóba, addig megpróbálhatod kézzel feltenni.
-
-Ben-
veterán
Lehet, hogy az nV szoftver lesz a beteg. Ahogy látom, Radeonod van. A Linux kezdőknek topikban többen is írták, hogy AMD/ATI kártyákkal nagyon smooth minden, míg az nV kártyákkal nem feltétlenül. Én meg pont azért erőltettem az nVidiát, mert régen erőteljesen szívtam az ATI -val....
Erősebb kártyákkal állítólag nincs gond. Ismerősnek GT 1050 dorombol a gépében és nagyon szépen működik minden. Csak pl. nekem teljesen felesleges egy GT 1050, ezért is vettem egy alap kártyát, ami játékra nem alkalmas, netezésre és sok más egyéb dologra viszont - elméletileg - tökéletes, hisz a 9400GT is az volt.
Mindenesetre, ha a szoftver jelenti a problémát, akkor erre aligha lesz mostanában megoldás.. Nyílt és zárt driverrel se akar normálisan működni. -
-Ben-
veterán
Csak ez az egész azért érdekes, mert a GT710 elődje egy nagyon öreg 9400GT volt, amivel a 16.04 jó ideig kiválóan működött zárt driverrel. Aztán jó kérdés, hogy mikor, de elkezdett akadozni a gépezet. Feltételeztem, hogy az öreg SSD vagy a szintén nem túl fiatal 9400GT elfogyhatott, ezért lecseréltem az SSD-t és a VGA-t is, majd telepítettem a 18.04 -et. Nagyjából ugyanaz a helyzet, de a 18.04 -nek köszönhetően egy kicsivel még rosszabb.
Kíváncsiságból kipróbáltam Live a 14.04 -et, mivel az még nagyon simán hasított. Nos, a böngészőben való görgetés már azzal se valami „smooth”. Sok program megnyitásától kevésbé, de azért megfekszik a gép.
Ebből gondoltam, hogy hardveres a gond, mivel már mind a zárt mind a nyílt driverek végig lettek próbálva és korábban még a szerényebb képességű nyílt driverrel, illetve gyengébb videokártyával is remekül működött minden.Nézegetem a htopot. Egyértelműen a firefox és a gnome-shell húzza a processzort. Teszek egy próbát az xfce -vel is, de tulajdonképpen az asztali környezet akadozását a KDE is megoldja, hisz KDE -vel minden vaj simán működik, kivéve a böngészők.....
Egyébként lehetséges, hogy egy GT 710 már általános használatra is kevés?
Nagyon furcsállom. Emlékszem még a régi időkre, amikor egy 8600GS tökéletesen vitt mindent a 9.04 alatt. -
-Ben-
veterán
it8720-isa-0290
Adapter: ISA adapter
in0: +0.93 V (min = +0.00 V, max = +4.08 V)
in1: +1.54 V (min = +0.00 V, max = +4.08 V)
in2: +3.34 V (min = +0.00 V, max = +4.08 V)
+5V: +3.01 V (min = +0.00 V, max = +4.08 V)
in4: +0.00 V (min = +0.00 V, max = +4.08 V) ALARM
in5: +3.02 V (min = +0.00 V, max = +4.08 V)
in6: +0.02 V (min = +0.00 V, max = +4.08 V) ALARM
5VSB: +3.04 V (min = +0.00 V, max = +4.08 V)
Vbat: +3.10 V
fan1: 1490 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 1214 RPM (min = 0 RPM)
fan4: 1231 RPM (min = 0 RPM)
temp1: +34.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp2: +34.0°C (low = +127.0°C, high = +127.0°C) sensor = thermal diode
temp3: +49.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
intrusion0: ALARM
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +41.0°C (high = +80.0°C, crit = +100.0°C)
Core 1: +39.0°C (high = +80.0°C, crit = +100.0°C)
Core 2: +39.0°C (high = +80.0°C, crit = +100.0°C)
Core 3: +39.0°C (high = +80.0°C, crit = +100.0°C)
Jók, de ilyen kész motyóban nem gondolkodom. Akkor nem tanulok. 
Ha viszont megértem egy Debiannal az alapokat, kicsit mélyebbre túrok a témában, mind a laptopom, mind a házi/kis-irodai NAS-omhoz van/lesz tudásom, hogy mit, hogy, merre. A szívást meg vállalom. Igazából elég nagy súllyal szól erről is a dolog (tanulás), nem csak a végeredményről.
Eladogattam. Zúgott.
Nem ragaszkodom hardcore módon a raid-hez, csak egyelőre nem nagyon volt más a fejemben, persze, nézegettem CUPS-ot, meg sync dolgokat, alternatívákat, amik félig vagy egyáltalán nem on-the-fly és más szinteken is dolgoznak, de ott még nem járok fejben sem.
aztán fallback autodetect-re és mikor feloldottam mindent és raid is beugrott, összekaparta magát azonnal az LVM is és hibátlanul felállt a rendszer.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Per pillanat desktop üzemmód, polcon szétszórva, külső USB dokkolóban, melyik hol merre és mikor hogy használva, teljes káosz a könyvtáraimban, stb.
Atyaég .. 
, de azért többet hoznék ki belőle, mint a Windows-om és a notis Debianom, amit most nyújt.
Új hozzászólás Aktív témák
- Antivírus szoftverek, VPN
- 27%-OS ÁFÁS SZÁMLA I Jogtiszta Microsoft digitális és fizikai termékek I DIGITALKEYZ.COM
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Assassin's Creed Shadows Collector's Edition PC
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- AKCIÓ! AMD Ryzen 7 3800X 8mag 16szál processzor garanciával hibátlan működéssel
- AKCIÓ! ASUS B460M i7 10700 16GB DDR4 512GB SSD GTX 1080Ti 11GB KOLINK Observatory TG TT 600W
- LG 55C4 - 48" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen7 CPU
- BESZÁMÍTÁS! Asus B550M R5 5600X 32GB DDR4 512GB SSD RTX 3060 12GB THERMALTAKE Commander G41 700W
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest