- Kábeleket és csövezést rejtő "kirakatház" a GameMax logójával
- Felvarrták az Arctic rackmount rendszerekhez szánt CPU-hűtőjének ráncait
- Háromféle kivitelben, és nem kis kapacitásokkal jönnek a Micron 6550 ION SSD-i
- Már a Samsung sem szolgálja ki modern AI lapkákkal Kínát
- Havazáshoz igazított kiadás kap a Steam Deck OLED
- Milyen SSD-t vegyek?
- Milyen notebookot vegyek?
- Azonnali informatikai kérdések órája
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- 3D nyomtatás
- Zeneszerkesztő és DJ topic
- VR topik (Oculus Rift, stb.)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kormányok / autós szimulátorok topikja
- Soundbar, soundplate, hangprojektor
-
PROHARDVER!
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
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.
-
#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
#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.
-
anorche1
őstag
Nem tudtok ajanlani egy kepnezegetot, ami tudja kezelni az iphone -nal keszitett heic kepeket? Gimp megnyitja, de az nem igazan hasznalhato kepnezegetonek.
Google -ben csak jpeg -be konvertalasra talaltam megoldast, de en meg szeretnem orizni az eredeti kepeket."It never gets easier, you just go faster." Greg LeMond
-
#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.[ Szerkesztve ]
-
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!
:)
-
Vladi
nagyúr
válasz
Volkov
#26960
üzenetére
Passz, de bacénél vigyázz ezekkel az áramszünetekkel. Mert nekem is ilyen van, régebbi modell és az áramszünettől megadta magát.
Most azt csinálja, hogy szépen leáll, majd áll, majd egyszer csak elindul. Sebaj, kapott kapcsolós elosztót, oszt induljon nyugodtan.
il sole non sorge più ad Est!
-
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.
-
-
#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?
Switch Tax
-
#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
letixdon't panic! ... http://www.letix.hu - linux parancsok
-
#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.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#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.)
[ Szerkesztve ]
Switch Tax
-
#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?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#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
letixdon't panic! ... http://www.letix.hu - linux parancsok
-
#26974
MasterMark
titán
letix
#26973
-
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
-
#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.
-
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?| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'
-
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.
Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesü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
letixdon't panic! ... http://www.letix.hu - linux parancsok
-
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.
https://www.coreinfinity.tech
-
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.Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
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 ?
Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
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
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.
Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesü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.Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
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.Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
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...Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Lenry
félisten
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
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
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.
-
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.
https://www.coreinfinity.tech
-
sh4d0w
félisten
válasz
bambano
#26991
üzenetére
Ezzel a módszerrel minden kötetre külön meg kell adni jelszót. Próbáltam, baromi kényelmetlen.
Egyébként ha a LUKS van a RAID-en, akkor az egy titkosított layer a block device-on és egy másik transzparens block device-ot kínál fel LVM és vagy FS felé.
https://www.coreinfinity.tech
-
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.
-
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.
Egyébként lehet, hogy végül 500 -as széria lesz. Majd amelyik összejön.... 
![;]](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.
és minek mennyi a
Atyaég .. 
, de azért többet hoznék ki belőle, mint a Windows-om és a notis Debianom, amit most nyújt.
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.
az új, 3x4TB Seagate NAS HDD vinyóimra. Túléltük. Mondjuk tényleges adatom volt sok rajta, de "bukható", semmi critical.
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: HC Pointer Kft.
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest