- Bemutatkozott a Transcend SSD-inek zászlóshajója
- Sugárhajtómű ihlette a Zalman CPU-hűtőjét, de nem az üzemzaj tekintetében
- Félreértések az FSR 4 és a PlayStation 5 Pro körül
- Nem tetszik a Procon-SP-nek, hogy a Nintendo távolról kivégezheti a Switch 2-t
- Megcélozta az NVIDIA-t a 2 nm-es node-jával a Samsung
- Milyen videókártyát?
- ThinkPad (NEM IdeaPad)
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen egeret válasszak?
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Házimozi belépő szinten
- GeForce RTX 5050 VGA-k a Palit értelmezésében
- BIOS frissítés
- A Micron újszerű módszerrel javítja QLC-s SSD-jének sebességét
- Melyik tápegységet vegyem?
-
PROHARDVER!
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
Dißnäëß
nagyúr
válasz
CPT.Pirk
#105025
üzenetére
Margóra:
sudo cryptsetup benchmarkkiadja, mi mire képes, egy másik ablakban tudod mellé nézni, hogy mekkora CPU árán. Persze minden eszközre, hisz ez teljes számítási kapacitást mutat, amit a rendszer elérhetőként tud.. 2+ eszköz egyszerre írva (encrypt) vagy olvasva (decrypt), pl. titkosított raid lába, nő az igény, ha pedig nem fér bele a motyó az itt mutatott maxba, akkor lesz a titkosítás bottleneck. -
-
Dißnäëß
nagyúr
válasz
Edorn
#104971
üzenetére
[link]
Parancs csekkolni hogy melyiket tudja a procid a cikkben.De megnéztem gyorsba, nekem is AM4 van, ez Zen 3, ez x86-64-v3-at tudja, v4-et már nem, mert ott bejön az AVX512, tehát AM5 tudja csak.
Az 5600-ad tehát v3-al bezárólag jó, így v2-re is.
CentOS után állítólag Alma és Rocky van, mint két út, Rocky-t is szeretik..
-
#104922
Dißnäëß
nagyúr
Sidorovich
#104917
Dißnäëß
nagyúr
válasz
Sidorovich
#104917
üzenetére
Aha
És köszi !!! 
-
#104914
Dißnäëß
nagyúr
Sidorovich
#104900
Dißnäëß
nagyúr
válasz
Sidorovich
#104900
üzenetére
BF4 ?
-
#104871
Dißnäëß
nagyúr
Sidorovich
#104868
Dißnäëß
nagyúr
válasz
Sidorovich
#104868
üzenetére
-
Dißnäëß
nagyúr
válasz
Rowon
#104844
üzenetére
Erre tippelek én is, de határeset ez a korszak még.
PCIe esetén elég egy használt-jó VGA, ami tud pl. VP9-et és h.265/HEVC-t, az AV1 a jövő, de elég soká lesz még mindig igazán elterjedt. Mindenesetre YT említettekre tud szépen fallback-elni, lehet h.264-re is..
Szóval a kolléga helyében behúznék hardverapróról vmi nVidia 1030-1050-et, 1650-et és vidámság. Ha lehet, passzívat, az nem zúg.
AV1 már nyújtózósabb, RTX 3050 a belépő.
A nemrég barátságosabbá vált linux-driver-nvidia-együttműködés miatt már maradnék NV-n.
-
Dißnäëß
nagyúr
Cache vinyó: NE.
Cache SSD: aham.
Egy régit is befoghatsz, ami szedi a lábát, 2 HDD esetén is még szekvenciálisban jobb lesz kicsit, de a sok random olvasásban pláne. Mikor belépsz egy rengeteg fájt vagy könyvtárat tartalmazó poolba, nem darálgat hosszabb ideig, mire beolvassa. -
Dißnäëß
nagyúr
Semennyire, a raid tömböd nagyonhamar gyorsabban tud olvasni, mint a cache-nek (tisztázzuk: READ cache-nek, azaz L2ARC-nak) használt HDD.
Felejtsd el, a legbikább NVME-t kell L2ARC-nak betenni, lehet kicsi is, vagy amire a pénzed futja, de gyors legyen, nálam 4 HDD olvas 700MB körül (persze 1 nagy fájlt, nem sok aprót millió seek-el), szóval egy SATA SSD is sovány lenne (kettő már okébb)... na az megküldi rendesen a pool sebességet. Mondjuk a nagyobbak többet is bírnak (TBW) és jót is tesz úgy mindennek általában.
VM-ek (és DB-k és 1-2 dolog) a default async helyett sync módon írnak a poolra, azaz akkor tekint a rendszer valamit kiírtnak, ha az ténylegesen kiírásra kerül... így arra LOG (SLOG) device-ot érdemes csinálni, szintén SSD. Ez write cache, míg az L2ARC read cache csak.
Az egész pool alá pedig lehet SATA SSD-kből, minimum 2-utas mirrorból, de inkább 3-ból (mert ha bekrepál, befosik a teljes pool) special device-t csinálni, ami a metaadatokat tárolja itt (nem pedig a HDD-n) illetve default tán a 128K-nál kisebb fájlokat, de ez állítható, pl. minden ami 8 megánál kisebb, erre jöjjön, minden, ami nagyobb, a HDD-re. Special device-t utólag is lehet hozzáadni meglévő pool-hoz, viszont csak új írások metaadatai kerülnek az SSD mirrorra, a meglévők már nem, ezért érdemes pool létrehozáskor meglépni ezt, akkor az optimalizált.
Fullextrás esetben lenne egy pool és hozzá special device (2-3 utas mirror SSD), log device (1 vagy több SSD) és cache (1 vagy több SSD) egyaránt.
Ezekből a LOG-ot érdemes tükrözni, de ha nem tükör, nincs tragédia, akkor sem, ha meghal (max pár utolsó tranzakció vész el), régen ez baj volt, de már rég kiszögelték a ZFS-ből. Ettől függetlenül olcsó az SSD, két SATA-sat simán be lehet fogni erre a célra tükörben, a LOG-ra durva írás nem megy, inkább több kicsi.
A cache (L2ARC) SSD-t bármilyenre lehet venni, kommersz szar is lehet, nem fontos enterprise és akár stripe-ba is teheted egy társával, dupla sebesség (raid 0 ekvivalens). Ha hullik, belassulsz, de kb. ennyi történik, semmi különös. Én valami nagysebességű vihargyors NVMe-t fognék be erre és elég 1 db.
LOG eszköznek 1 vagy 2-utas tükörnél érdemes PLP-s Enterprise szintű SSD-t venni, hogy ha elmegy az áram, be tudja még fejezni a legutolsó megkapott adat kiírását az SSD. Nem durván kötelező, de ajánlott.
Special device már metadata szint + kicsi fájlok, ez érzékenyebb terület. Én ide szintén csak enterprise, jó írástűrésű SSD-ket fognék be, de PLP-s legyen, itt nagyon fontos, hogy be tudja fejezni a legutolsó megkapott adatot minden SSD benne, ha elmegy az áram hirtelen. Elméletben a ZFS ugye CoW, ha lemegy az áram, nincs korrupció a fájlrendszeren, mégis ajánlják. Enterprise SSD-k ilyenek.
Szóval SATA SSD-kkel meg lehet oldani mindent, ami nem cache (L2ARC), mert nincs durva szekvenciális írás-olvasás róluk. A cache eszközt érdemes a sebesség miatt NVMe-re venni.
Amit én még javaslok, az az ashift=12, a szektor méretet amit a ZFS alapegységnek használ, érdemes a default 9-ről megemelni (kettő a kilencediken, azaz 512 bájtról kettő a tizenkettedikre, azaz 4K-ra), bár sok 4K natív diszken felismeri a ZFS és ezt használja.
Egyre több SSD jön (még azért nem mind) 8k szektormérettel, és mivel egy pool-on belül az ashift érték minden eszközre ugyanúgy érvényes, a gyors mindenféle írási és olvasási cache és metaadat SSD-k optimális kihasználtsága miatt érdemes akár 8K-ra venni a szektorméretet (ashift=13), ez a 4K-s vagy 512b-s HDD-knek sem gond amúgy, hiszen a kisebb számok többszöröse.
atime off-ra, compression ízlés szerint, dedup off (ez a default amúgy) és akkor nem falja a RAM-ot (a rendszer RAM felét elveszi, de amint kéri egy app, visszaadja), ha esetleg használnál valami gluster vagy egyéb elosztott fájlrendszert felette, akkor érdemes az xattr=sa-t is beadni neki, nem nagy plussz metaadatban.
- cache (L2arc) bármekkora lehet
- special már nem feltétlen, nézd meg a statjaidat (zdb -Lbb <pool>) és látni fogod, melyik soron mi az érték a metaadatokra JELENLEG, special nélkül.. de olyan pool teljes méretének 1%-a egészséges lehet (persze nagyon pool függő, ezért érdemes statot nézni). Ha a special betelik, a HDD oldalon folytatódik a (vélhetően) most is megszokott módon a metaadatok és kis fájlok tárolása, szóval nempara, max lassulsz
- ZIL/SLOG szintén ízlés szerint, azért ne 32 Gigásat.. Szóval összességében egy komoly sebességű pool abszolút valid, de érdemes egy marék SSD-vel nekiállni. A legkönnyebb a cache eszköz, ha van egy SSD-d elfekvőben, bármikor hozzáadhatod az egészet, vagy csak egy partíciót róla (felül lesz írva), pl. mondjuk ha overprovisioning-elsz, hogy ne használja a teljes tárterületet, így valamivel lassabban kopik.
Érdemes még a recordsize=1M-et is beadni neki, 16M-ig lehetne menni, de itt már nincs szignifikáns sebességkülönbség és sok helyen azt olvasni, hogy a default 128K és 1M között az optimum. Ez maximum érték, tehát ami ennél kisebb, az kisebb record-ba lesz kiírva, ami ennyi vagy ennél több, az pedig úgy. Hatása van a szekvenciális olvasásra, a tömörítés hatékonyságára, a párhuzamosíthatóságra és még jópár dologra, szóval egy 1 megás recordsize beállítással elég faja lehet egy vegyes mindent tartalmazó pool.
(Ha csak és kizárólag nagy fájlok mennek rá, ami mondjuk nagyobb, mint hasraütök, 1 giga, lehet 16M is a recordsize érték, de marginális a haszna, 1M ideális max közeli, azt mondják).
A nap végén rá fogsz jönni, hogy miután tanultál egy rahedli dolgot a ZFS-ről, úgy szar a pool-od, ahogy van.
Ezen mindenki átmegy, aki ZFS-ezik
(Szintén zenész).Iyenkor jön az, hogy ki mindent valahova máshova, majd HDD-k legyak, faszapool létrehoz, spéci device-okat alá betol, na és majd csak ekkor mehet minden rá vissza, kölcsön HDD-t megköszön.
-
#104789
Dißnäëß
nagyúr
tordaitibi
#104783
Dißnäëß
nagyúr
válasz
tordaitibi
#104783
üzenetére
Cache-nek kiváló, míg szét nem hal.
-
-
#104777
Dißnäëß
nagyúr
tordaitibi
#104772
Dißnäëß
nagyúr
válasz
tordaitibi
#104772
üzenetére
Dehogy, az optika halott. Kapni, csak minek.
SSD-t se, áramszivárgás, melyik meddig őrzi meg az adatot, ha évekig nincs bekapcsolva.HDD, de nem a gyártóban bízunk, hogy jót csinál nekünk, se nem a nagykerben-kiskerben, hogy szépen kezelik őket. A gyártó szart csinál, a szállítók pedig rugdossák őket, ebből indulunk ki. - - - > minél több, annál biztosabb, hogy túlél a backup is
Marha egyszerű.Szóval linuxos vagy windows-os (vagy urambocsá, BSD-s) raid jellegű cucc ami szóbajöhet. Akinek nincs sok pénze, mirror-ozzon, vagy 6 használt-kisebb-olcsóbb HDD-vel raid6 jellegű dolgok, egyszerre 2 már tényleg ritkán hal.
-
Dißnäëß
nagyúr
válasz
urandom0
#104770
üzenetére
Ennyi.
Nálam amúgy 2TB WD Green hullt anno. Az a szutyok... és volt több is, huh, elpasszoltam míg 100/100 volt a maradék. Érdekes módon a meghalt Green is 100/100 volt, mikor letettem.
Egyébként enterprise környezetben is hibatűrőek a backup-ok. Jó esetben
De ahol én voltam infra architect, ott mindenképp.
Itthonra nem kell.
Snapshooooooooooooooot ruuuulzz![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Dißnäëß
nagyúr
Nyilván akkor van backupod, ha vissza is tudod állítani.
Így van.Raid5 nekem sem hullt még rebuild alatt, de nagyon érzékenyek rá "egyesek" IT-ban és kapja az ember a fejére, hogy így butavagy, úgy butavagy, jújmekkora risk, aztán nesze, életemben nem láttam még ilyet (hálistennek) saját magamnál. Persze, létezik, csak na.
Végülis, mindenben van valami tradeoff, az esélyek csökkentéséről szól az egész, ez meg itthoni felhasználásban nagyon szubjektív megítélés alá esik.Felmegyek a jövőben igencsak egy 6-lemezes raidz2-re, de itt stop.
Majd írd már meg, mi lett az egymásutáni clear & scrub indítás-leállás dologgal, mert kis gugli után egy srác ugyanígy járt és kitisztult a pool-ja ezzel.
-
Dißnäëß
nagyúr
Mert már jártam úgy egy WD-vel, hogy levettem fél év után a polcról és félig felpörgött, aztán "áhhh, elfáradtam" és nyekk. Szar széria is volt, mint megtudtam később, de azért kellemetlen élmény. Buktam fél évnyi hobbifotós raw anyagot, ez volt a tanulópénz. (Túl azon, hogy az élest én csesztem el).
Vicces, amikor a backup "backup"-ja az éles
, "valamelyik csak jó lesz" alapon, csak hát az ember a backup-ot nem akkor szokta elővenni, amikor az élesen minden oké, hanem amikor NEM oké, ergo onnantól a backup az egyetlen hely, ahol az adat megvan. Legyen az egy normális hely, nem ? Sosem értettem, hogy egy élest érintő disaster esetén miért gondolják sokan, hogy az az egyszem HDD backup jó lesz úgy, pláne annak fényében, hogy ugyanakkora terhelést kap egy helyreállítás során a backup HDD, mint amikor raid5-ben egy HDD megmakkan és beindul a resilvering (és makkan a terhelésre egy másik - ez a nagy félelem a raid5-től).
Nem logikus a backup-ot is redundánsan tárolva tudni, fullos logikai védelemmel ? A visszamásolás sebességéről nem is beszélve, nálam azért megvan a 700 mega átlagban, ez azért egy fokkal szebb, mint 1db HDD amikor nekiesik a teráknak.
Próbáld meg zpool clear után a scrubot elindítani, majd le is állítani egyből.
-
Dißnäëß
nagyúr
Ezt a rizikót bevállalom, amiket említettél. Végülis a nap végén ezen múlik a dolog.
Viszont kitett backup HDD-ből is minimum kettőt vennék, mirror-ban. Ami nemhatékony méret ügyileg, így abból is 4 lenne akkor már.
És a ZFS-ben nem csak maga a raid mivolta a csábító, hanem az ezzel járó integrity. zpool clear megvolt ?
zpool scrub <pool> megvolt ? -
Dißnäëß
nagyúr
Igen, ez az általános mantra, aztán a Reddit ZFS fórumán és még pár helyen nem csak jómagam, de többen is elég szép kis beszélgetésbe keveredtünk eme mindset szemellenzős híveivel (nem Rád utalok).
Szóval igen, ez egy alapvető igazság, de nem a teljes igazság.
Ahogy az sem, hogy a ZFS egy fájlrendszer (ahogy sokan hiszik).Egy szó mint száz, én azon ZFS-felhasználók táborát gyarapítom, akiknek nincs külön backup-juk, mert annyira "ügyes", hogy okafogyottá válik.
Persze a backup backupjának is legyen backup-ja, igen, hogyne, ez a legtutibb
(bármire is él a világon), de azért a földön maradva, itt TÉNYLEG nincs rá szükség. Egyszerűen semmi értelme egy több lemezes ZFS exportált poolt kitenni a polcra, hogy ott álljon, miközben el is érheted az adatokat rajta. Semmi különbség.
Jó. Ha villám hasít a gépbe és mind a 4 HDD-m odalesz, mert keresztülmegy mindenen és megmakk, akkor vessek magamra, oké. Akkor a polcos backup győzött.
De ilyenben - egyelőre - nem hiszek, tele vagyok védelemmel (a gép előtt is).
Ha nem ZFS lenne, ugyanazt mondanám, amit Te amúgy, mert tényleg egyetértek.
-
Dißnäëß
nagyúr
Dettó.
Ááá próbáltam VirtualBOX alól (W10 alatt) odaadni a 4 diszket direktben a Linuxnak, kissé mókolós, de nem is ez, hanem unsafe mai napig
, ennyi éles adatot nem buknék, családi képek és minden egyéb atyaúristen kb.De ha ezen reszelnének kicsit a jövőben, akár működne is (stabilan, így értem).
Most egyelőre W10 tényleg csak Adobe cuccok + 1-2 játék, Linux alatt pedig minden más.
A tv-nek és a telónak (wireguard-on keresztül) NFS-el adom a cuccost, bevált, de a sharing kb. ennyi.FreeBSD régóta mocorogtat. Filózok, miben adna többet a Debilnél.
Érdekelni érdekel, csak a mai világban már 10x meggondolom, mire áldozok időt, kevés a 24 óra. -
Dißnäëß
nagyúr
Igen.
Sok különböző területen nagyon nagyot jöttek a disztrók az elmúlt 10 évben, hw támogatás, szoftver kompatibilitás (fájlrendszerek, driverek, stb). Emlékszem gimi végén még mit össze sz**tunk 1-1 rendszerrel, ma meg pfff. szinte katt-katt-katt, ha olyat választasz.
Windows alá kéne még a ZFS-t rendesen bevarrni, az OpenZFS eléggé le van maradva, továbbra sem merem a NAS-om ZFS diszkjeit Windows-al megnyittatni, még nem kiforrott. De jön ez is hamarosan (remélem) feature parity szintre a Linux verzióval. Szerk.: stabilitás pláne.
-
#104736
Dißnäëß
nagyúr
tordaitibi
#104724
Dißnäëß
nagyúr
válasz
tordaitibi
#104724
üzenetére
Akkor ezért ilyen rohadt jó a BF nálam 3050-en. Végre tudom.
(W10). -
Dißnäëß
nagyúr
-
#104704
Dißnäëß
nagyúr
IstvánLászló
#104702
Dißnäëß
nagyúr
válasz
IstvánLászló
#104702
üzenetére
Debian is hasonló irány, 2023-ban fogalmazódott meg konkrétabban..
Most itt tartunk: [link] -
Dißnäëß
nagyúr
válasz
ubyegon2
#104685
üzenetére
Gyakran ilyen idiótauserbarát.
Tapasztalat.Amúgy az
apt removehelyett azapt purgeis jó, ha soha többé nem kell egy adott csomag. Ez annyival tud többet, hogy még a csomag által kreált és remove-kor otthagyott-otthagyandó config mappákat és fájlokat is törli, írmagja sem marad a csomagnak és ha újra felteszed, mintha szűz terepre tennéd és soha nem lett volna feltéve, olyan. Legalábbis definíció szerint, mert nekem már a purge is hagyott ott maradványt, de ritkán.apt autoremove -ynéha olyat is elvett régen, ami meg mégiscsak kellett másnak, így az eltört indításkor, de ha nincs sok kézi hack-elés és "tudja" a rendszer jól nyilvántartani a függőségeket, nem szokott galiba lenni.Szerk.: a ph színez, nem én.
-
-
Dißnäëß
nagyúr
válasz
cigam
#104654
üzenetére
Az Ubuntu 24 LTS-t stabilnak nevezi a Canonical? Igen
A Debian xid-et testing-nek nevezi a Debian? Igen.
Nem.
[link]1. Először is sid, nem xid.
2. A sid unstable, nem testing.
3. A sid mindig sid, nem változtatják a nevét soha és mindig unstable is egyben. Ez olyan, mint valami pipeline, hogy befele is jönnek csomagok és kifele is mennek (testingbe).
4. A Debian testing és stable nevei változnak, amikor a testingből stable lesz, a stable-ből pedig oldstable (security-t még kap az oldstable asszem).Tehát SID alatt eggyel érettebb a testing, most a Trixie (már nem sokáig) fantázianévvel, a 13-as főverziószámmal. Ez alatt pedig a mai stable a bookworm (12-es verzió).
Nemsokára a Trixie lesz a stable és a Forky lesz az új testing, ami a majdani 14-es stable jelölt.
Vagyis ha az Ubuntu 24LTS stable a Debian xid testing ágára épül, akkor most stabil, vagy teszt?!
A 24 LTS a Debian stable-re és testingre egyaránt alapul (kicsit jobban belenézve) és ha a Canonical azt mondja rá, hogy ez az Ubuntu terminológiában az ő stable-jük, akkor annak tekinthető és fejben el kell vonatkoztatni attól, hogy ez Debian szemmel nézve stable-nél kicsit frissebb, kicsit kevésbé stabil. Mert a Canonical így osztályozza az érettség mércéjén a saját disztróját.
Azaz az Ubuntu LTS egy stabil kiadás, mehet szerverre mindenhova, sokáig élő support-al, az más, hogy a mögötte lévő Debian még szigorúbb követelményeket támaszt a saját stable kiadásaihoz, így tényleges stabilitásban az Ubuntu LTS-ek valahol Debian stable és Debian testing között vannak.
Amivel semmi gond nincs, nekem desktop a testing már 10+ éve és múltkor még egy AMD-Nvidia váltást is úgy túlélt, hogy csak pislogtam, pedig már rákészültem az atyaúristenre is, hogy na itt túrni kell.. OK, ez csak egy példa. De ha a Debian Testing ennyire stabilnak nevezhető (szubjektíven megítélve), akkor az Ubuntu LTS is tök oké.
Csak Ubinál vannak disznóságok, úgyhogy én Mint-eznék.
De amúgy nincs rizikó, szedj le egy igazi Debian Testing netinst-et és told fel egy virtuális gépben egy Gnome-al, KDE-vel, Cinnamonnal, ami jólesik ... szerintem rendben van.
Pár hete a Budgie desktop-ot próbálgattam, marha szép.
A Debian kényes ponton nem vérzik, amúgy meg minden disztróban van glitch, kérdés, hol.
Testing-el nagyon jól el lehet lenni, nálam a "mission-critical" NAS-on is testing van, a ZFS-nél nincs különösebb nagy lag egy új verzió esetén és szándékosan nem is sietek a frissítéssel mindig, pont jó..
Kernelben viszont már várom a testingre is a 6.15-öt, lényegesen gyorsabban töröl exfat-ról, mint a mostani (nálam épp aktuális) 6.12.31 [link]
De azért a rolling disztrósokat nem szoktam akkor sem irigyelni, vérszopás tud néha lenni és akkor az nagyon anyázós történet.
-
#104659
Dißnäëß
nagyúr
fekete.puma
#104653
Dißnäëß
nagyúr
válasz
fekete.puma
#104653
üzenetére
QEMU/KVM. Lehet más is így van ezzel..
-
Dißnäëß
nagyúr
válasz
ubyegon2
#104648
üzenetére
Így így, testing-en vagyok és már 13-as háttér van
Egyszercsak egy (kézi) update-em után ez lett. "Jééééé... oké köszi".Amúgy meg elvileg hard freeze-ben vagyunk. Már nem sokáig, de időpont nincs kitűzve.
@cigam: [link]
Debian-nál egy folyamnak kell elképzelni az egészet, ahol egy adott "unstable" csomag miután már átment X időnyi tesztelésen és/vagy bug-nemjelentésen, azt elkezdik "vélhetően nem véres a torka" minőségűnek tekinteni és unstable-ből bekerül testing fázisba. Még itt is jöhet ki baj és arra fix, de egyelőre nem stable. Stable-nek sok feltétele van, idő is, security is..
Debiannál ez nemkicsit összetett, de valahogy zseniális mégis.
Szemléltetésképp.. én ezen az infografikán biztos elméláztam egy fél órát
Igaz, 2012-ig megy, de durva eltérés most sincs.Ebből az alap logikát a komplett release kezelésre meg lehet már sejteni.
-
Dißnäëß
nagyúr
-
Dißnäëß
nagyúr
válasz
ubyegon2
#104638
üzenetére
Köszi az infót, nem követtem egy ideje (fél-1 éve néztem rá komolyabban).
Hát igen, RHEL is rég volt, mikor szép volt. Az ilyen nagyok előbb-utóbb kurvulnak vmilyen irányba, shame..
Amúgy néha előveszek erre-arra csak amolyan "challenge" szinten RedHat derivatívát, hogy ne maradjak túlzottan a magam kis zárt .DEB világában
és DistroWatch gyors infói mentén a CentOS Stream / Alma / Rocky hármasból a Rocky-t választva (ha már a Debian is erős community alapú, legyen itt is ez) nem csalódtam, de uh, azért elsőre Alice in Wonderland, jé, ez így, jé ez úgy .. 
Nem űrtechnika, de szokni kell.
-
Dißnäëß
nagyúr
Hah ezek jó pontok
Igen, saját belakás azért van fél-1 nap pepecs, mire minden OLYAN, csak olyan ritkán csinálom én is, hogy van 1-2 script + txt fájokba leírva magamnak pár dolog
Mert a VM-eket, vagy egyéb "játszós" Debianokat csak minimálba felteszem gyorsba, aztán annyi.
Most pont ezekre fogok végre vmi terraform-ansible megoldást találni.
"Én nem, mert az első problémánál fel szokták adni
Mondjuk akiket én ismerek, azok máson sem nyomoznak, ha 10 percnél tovább tart valaminek a kitúrása." Nem akarom őket bántani, de vagy fiatalabb dzsenzík, vagy elfáradt veteránok, stimm ? -
Dißnäëß
nagyúr
Szerintem ez nagyon telepítő függő.
Tartok nagy iso-t is, ha legyaknák a netet holnap, legyen egy "DVD-m" róla.
De általában netinst, stable és testing is.
Stable minimált szoktam, még alap tool-ok se, csakis ssh, minden más off. Így megvan friss reboot után úgy 90MB RAM körül a Ryzen-en, nagyjából.
Utána ha kritikusabb gép, hagyom, de általában már hobbi VPS-ben is testingre felhozom, amíg még ilyen kicsi a telepített verzió, ne utólag kelljen többezer csomagot frissítenie.
Aztán kézzel pakolgatok fel dolgokat, alap tool-okat, egy szigorúan és jól bejáratott ösvényen megyek, semmi bloatware, pláne semmi telemetria és ilyenek.
De ez relatív könnyű.. fogom a legutóbbi fstab-ot, wwn alapú minden benne, így megtalálja ez is.. crypttab dettó, iptables dettó (szokogatom az nftables-t egy ideje), satöbbi. Igazából minden egy parancs, meg kevés (tényleg nem sok) conf mókolás.. exports fájl, pár saját scriptem is van már, csak enter és beállít mountpoint-okat, jogokat, megcsinál nekem ezt-azt..
Újoncként meg kb. kiválasztok egy DE-t (legyen Cinnamon/KDE/Gnome) és ikszelek végig a telepítőben mindent, aztán reboot és van egy jó kis fully fledged Linuxom, amit elég nehéz megfektetni (a stable nagyon jó, még ha sokan kicsit húzzák is a szájukat a "korosabb" csomagokra, de hát mindennek ára van).
Én semennyire sem értettem még Linuxhoz anno és 3-4 év Suse után mentem át Debianra, "intenzív tanulóra" (desktop, daily driver + server felhasználás együtt). Szóval elmondható, hogy ezen tanultam.
A systemd-s balhé nem tetszett, majdnem Devuan lett.. de végül elfogadtam.
Hugomnak Mintet raktam. Ő laikus.
De egy kicsit is IT-s cimbinek szó nélkül merném ajánlani, hogy tanuljon ezen. Nem nagyon fog nonstop eltörögetni valami, vagy maga alá kakkantani.
-
Dißnäëß
nagyúr
válasz
ubyegon2
#104630
üzenetére
Magán az LM oldalon volt talán, hogy a hosszútávú stratégiájuk Ubunturól majd egyszer Debian alapot használni, úgy értem direktben, nem egy köztes Ubuntura építkezni. Ezért jött létre az LMDE és vélhetően eltűnik végleg, ha tesztelték eleget és meglesz a döntés. Addig Ubuntu alapú a mainstream Mint. Hogy ez a stratégia még mindig így van-e, nem tudom. Közben meglett, igen. Ha egyszer Canonical úgy dönt, az Ubit lelövi, vagy valami randaságot tesz vele, mint a nagy piros kalap, ott a backup disztró a Mint túléléséhez, HA még nem álltak át arra.
-
Dißnäëß
nagyúr
válasz
cigam
#104614
üzenetére
Legutóbbi infóim szerint az Ubuntu az, az LTS-ek jobban talán, mint a normálok, de vegyesen szednek unstable-ből és testingből is, sok saját teszteléstől megkímélve magukat így. De vegyes a kép amúgy.
Nem szoktam fogadni. Mindenesetre, nem Fedorából, se nem Arch-ból építkezik, pláne nem Suse.. egyértelműen Debian derivátum (ami szvsz fasza dolog, de ez ízlés dolga kb, mint az, hogy szereted-e a gulyáslevest).
-
Dißnäëß
nagyúr
Szerintem nem durva, de lehet rosszul látom... , a stable-t felteszi egy grafikus felülettel, akár default akár mittomén, Cinnamon, tök jól használható, alig "harcore-abb", mint egy Ubi, vannak a common csomagok, amik minden szart hoznak magukkal, grafikus csomagkezelőtől kezdve wifi bas*tatón át az audio alrendszerhez soksávos EQ, satöbbi, tök jó, még az nvidia Optimus is megy jól (Intel CPU integrált VGA + nvidia egyszerre használata).
(Vagy csak én fejlődtem és nem tűnik fel már, de nem akarok ekkora arc lenni, úgyhogy mondjuk úgy, nem feltétlen durva liga a Debil)
Ha így nézzük, ő az anya, Ubuntu a gyerek, Mint és többi Ubuntu derivatíva az unokák
(Ezek mind Debian Testing-re épülnek amúgy, nem stable-re).Vidikártyákkal én se szeretek szívni, elég ha a driver megy szépen és kezeli a 4K 144Hz-et + kodekek, YT fullscreen nem röccen, VLC is folyékony és a CPU is nyugszik közben. Desktop módhoz 1-2 vidihez, YT, stb, kell. A proprietary driver nem is szivat, nekem tökjó.
Szervernél én is teszek rá magasan, a Pi4-en is csak CLI van, meg a szervertermin is. Sosem szerettem a VNC-t
meg ha már grafika van, az nagy overhead tud lenni (nem csak maga a DE, hiszen egy XFCE nem nehézsúly - ellenben egy KDE-vel - hanem a progik innentől, egy gparted hasonlókat tud, mint egy mezei parted, mégis 10x annyi fájl.. csak példa). -
Dißnäëß
nagyúr
Igen
Én is csak azért szívtam még egy viszonylag "gyöngéd" Debiannal is (ami régen sokkal hardcore-abb volt a 2000-es évek elején, mint ma), mert AKARTAM.
De még ezen is van úgy, hogy rengeteg a vakfolt.
Pl. X/Wayland és minden, ami grafika. Sosem érdekelt. Ezt sem ezen, sem máson nem fogom megtanulni. Sokan kántálják, hogy AMD és pont egy hónapja váltottam Ryzen internal GPU-ról GPU mentes Ryzenre és RTX 3050-re arra a pár játékra, amit régen toltam... az első, legrégebbi kártya-széria, ami tud normális AV1 dekódot is. Seamless átállás és hibátlan proprietary driverrel. (Persze, most már az open is nagyot fejlődik). -
Dißnäëß
nagyúr
A hopperkedés szvsz hipster dolog. Igazán kitanulni egy disztrót viszont sokkal nagyobb érték, mert kevésbé lesz olyan, hogy egy alapvetően - feltételezhetően jól - összeintegrált komplett rendszer egyik elemét csak SUSE, másik elemét meg csak Gentoo "nyelven" érti az ember, a harmadik akármin ülve épp. Ennek semmi értelmét nem látom. Egyes komponenseket viszont (mysql, redis, maga a linux, cron, rsync, ssh, luks, stb stb) egyetlen disztrón bőven ki lehet tanulni. Lehetőleg olyanon, ahol az automatizáció mértéke is csak közepes, mert ahol mindent kézzel kell összetákolni, az teljes agyhalál és elmegy az ember kedve tőle, ahol pedig minden hülyére automatizált, ott nem igazán történik nagy tanulás.
Mondjuk egy "szabadelvűt" otthonra (Debian) és megfelelő tesztkörnyezetben egy RHEL-vonalat a munkahelyre, mert ott gyakran az jön szembe. (Vagy Ubuntu még).
A VM-ek erre valók.
Egyébként kezdőkről volt szó, nem tanulókról vagy használókról. Lehet bárki úgy kezdő, hogy nem érdekli az egész, meg úgy is, hogy tanulni akarja. Attól még kezdő.
Nagyon nem mindegy, hogy egyből deriválni kezd, vagy esetleg előtte megtanul zárójelet helyesen felbontani.
-
Dißnäëß
nagyúr
Én azt is szoktam mondani, hogy meg kell becsülni, hogy feltételezetten mekkora lehet a mögöttük lévő community. Mert nem csak az a lényeg, hogy hány problémára esélyes a "tanuló", hanem hogy mennyire kap megoldást ezekre. Persze mondhatnánk, hogy tanulni csak szo**ssal lehet, de azért nagyon nem mindegy ennek mértéke és mennyisége.
Ilyen szempontból én spec. örülök, hogy SUSE-Debian vonalon kezdve, sok hülye kanyart téve az évek alatt több egyéb irányba (feleslegesen) végül maradtam a jó öreg Debiannál, abból is testing, ami sokkal inkább "stable" mint "unstable".
-
Dißnäëß
nagyúr
válasz
Dißnäëß
#104387
üzenetére
Látható, hogy a feloldás után az lsblk beteszi a virtuálisan létrejött /dev/mapper-es alias-okat az őalattuk lévő tényleges eszközhöz. (Ábrázolásban a fizikai alatt van a logikai a könnyebb megértés végett, de beszédben úgy mondjuk, az eszköz felett van a titkosított réteg és afölött a fájlrendszer az adatokkal). De ez míg nincs feloldva semmi, nem is látható, sőt, header hiányában még csak nem is sejthető. Persze, Ti mostmár tudjátok
de úgyis átalakítom az egészet a napokban, szóval mindegy is.Műxik szépen.
Na jó étvágyat !
-
Dißnäëß
nagyúr
válasz
cigam
#104382
üzenetére
Nem, mert adatot vesztenék és féltem őket.
De ki tudod próbálni Magad is:
1. hozz létre egy NTFS partíciót egy pendrive-on, vagy egy random fájlon, amit felveszel loop device-ként meghajtónak a tesztre.2. nézd meg, hol ér véget és adj egy ide mutató (vagy ennél későbbre) offset-et a cryptsetup luksFormat-nak (most már csak cryptsetup Format azt hiszem), így csak az emögötti részt titkosítod le vele. Az offset-et 512bájt többszöröseként kell megadni, szóval egy számológép kellhet..
mire eljutsz X gigára vagy terára, attól függ, honnantól szeretnéd titkosítani a diszket. Ugyanitt a luksFormat-nál adod meg, hogy --header és tedd ki egy külön fájlba (pl. root-ba, vagy tesztnél mindegy is), így a konténer elejére ő már nem fogja odarakni azt. 3. Linux reboot és/vagy a létrehozott titkosított helyett luksClose-al zárd le, mintha fel sem oldottad volna és akkor nem kell reboot. Bár luksFormat csak létrehoz úgyis, felnyitni nem nyitja azonal úgy emlékszem.. Mindegy is. Legyen zárva, innentől ez eltűnik a szemed elől, header hiányában semmi sem fogja mutatni a létezését.
4. Az NTFS partíciót BÁRMILYEN oprendszerből és BÁRMILYEN programmal lazán ráhúzod a mögötte lévő "üres" területre. Azért idézőjel, mivel üresnek látja minden program, miközben Te tudod, hogy ott egy LUKS konténer, amit fel tudsz nyitni, mert tudod, hol kezdődik, Nálad a kulcs és Nálad a header fájl is.
Bármelyik hiányában (offset mértéke, amit luksOpen-nek megadsz), kulcs vagy header, buktad az adatot. Szóval amiatt, mert nem látszik a feloldatlan partíció, bármikor bármilyen tool-al üres helyet látsz a helyén, innentől már gyerekjáték egy NTFS resize.
Amúgy hülyeséget írok, ehhez nem kell zártnak lennie. Particionáló tool-ok a felnyitott konténert nem veszik számításba (lásd üres Gparted képem), csak a fizikai diszket nézik, ott meg üreset lát, ergo így is engedi ráhúzni az NTFS-t, mivel ez neki üres hely. Ami aztán okoz rendesen galibát, ha írsz is utána erre az NTFS-re (SSD esetén pedig ahogy beindul a TRIM a titkosított régióra is, mivel fölé húztál egy rahedli üres NTFS szabad helyet, valszeg másodpercek-percek alatt szétkúrja az egészet, míg ha nem húzod fölé az NTFS-t, nem fogja bántani a kontroller, mert nem kap olyan TRIM parancsot az OS-től, hogy ott nincs adat. (Azt sem kapja, hogy van adat. Nem kap arra a régióra vonatkozóan semmit, ergo békén hagyja).
-
Dißnäëß
nagyúr
válasz
sh4d0w
#104380
üzenetére
Nem tudom mi vicces, én nem rúgtam Beléd...
Nem azon múlik egy LUKS régió (nevezük konténernek, nevezéktan most másodlagos) felismerése, hogy ismeri-e a fájlrendszert a Windows vagy sem, mert a GPT particiós tábla - mint ilyen - univerzális, azaz egy BSD, egy Linux, egy Windows, de lehet még valami bármi egyéb hülyeség is ugyanúgy ismerni fogja ezt és a benne lévő partíciók adatait, geometriáit, darabszámát. Csak a fájlrendszer kérdőjel bennük, ez valóban oprendszer függő, Windows csak a határokat látja, az ismeretlen beltartalomra ugat egy unformatted-et, viszont a Linuxok kezelői is ugyanezt látják. Hogy miért ?
Amit írsz a header-ről az igaz, csakhogy nálam a konténer header-je le van választva róla és máshonnan tölti be azt a rendszer a boot folyamat során, amit kihúzok a gépből amikor otthagyom. A kicsit is óvatosabb titkosítást érdemes ezzel indítani, mivel a header-ben tárolódik lényegében minden esszenciális adat a mögötte levő további adatok eléréséhez, ergo ha a header hiányzik, nem visszafejthető az adat még kulccsal sem. (Nekem nincs header backup-om, de van rá mód, ha sérülésnek lenne kitéve az adathordozó eleje).
A luks ad arra lehetőséget, hogy a header-t külön fájlba tegyük a konténerről leválasztva, így innentől a tényleges titkosított partíción vagy diszken valójában már csak a színtiszta betitkosított és emiatt randomnak tűnő "adatszemét" fog látszani, udisks, lsblk, blkid és minden más számára is, de még jobbat mondok, még a cryptsetup számára is (!), mivel header hiányában a büdös életbe fel nem oldja senki még kulccsal sem. Nem tudja, hol kezdődik a régió, mivel lehet offset-elni is azt X megával-gigával (nem tettem), nem tudja, milyen titkosítás típussal, kulcsok párja is itt tárolódik... minden hiányzik és autofelismerést maga a kriptográfia akadályozza. Nincs header, nincs visszafejtés, annak annyi.Ezért fordulhat elő az, amit látsz, hogy a gparted-em így néz ki és azt jelenti felénk, amit mutattam, miközben fel van nyitva a HDD és van rajta némi adat. A gparted ugyanis nem listázza be a felnyitott LUKS konténer tartalmát az őt tartalmazó fizikai (vagy logikai) meghajtóhoz, hanem csak azt nézi, mi van a tényleges meghajtón, az lsblk pedig kényelemből megteszi ezt nekünk, ha már feloldottuk.
No.
Bejöttem egy Rocky 9.5 Live ISO-ról, mintha külső avatatlan szem lennék, mondjuk betörő, aki felkarolta és elfutott a géppel és a haverja IT-s és nézegeti, mi van a gépen. Linux-al, mert "az pró".
Látható, hogy a 4db Seagate-en az égvilágon semmit nem lát, eddig ugyanaz, mint a parted. Vakon van. De hát miért is látna Header nincs, GPT nincs, semmi sincs, egy vacak bit nincs, ami értelmes adat számára, így aztán "üres, pucér" diszk. Windows erre ugat, hogy lehet inicializálni, én meg mondom, hogy *nyád azaz nem, mert a SAS kontrollert komplett kikapcsoltam Device Managerben.
Dettó. Lehet particionálni, akármi.De ha hexa editorral esne neki valaki bármilyen low vagy nemlow level módszerrel, akkor sem fog mit látni a csomó "hülyeségen" kívül.
Természetesen blkid az üresnek hitt drive-on használhatatlan, semmit nem mond, a cryptsetup pedig onnan tudja, hogy hova kell nyúlnia header-höz (majd onnan a tényleges adat részhez), hogy megmondom neki, hogy
1. hol találja a kulcsot
2. hol találja a header-t
3. mi a felnyitandó HDD (wwn alapján /dev/disk/by-id/wwn-...)
4. és ha van esetleg offset, még annak mértékét is megmondom.. különben előző pontok hiába pipa, elbukik a kinyitás és marad a nagy semmi nézése.
Azt látom, többen nem értitek, remélem így tisztább.
(Szól cigam-nak is, no offense, Neked mindjárt külön) Ha visszamegyek a normál rendszerembe mindjárt, ami feloldja /etc/crypttab-ból a drive-okat, látni fogjátok, hogy az ottani lsblk mindegyik seagate alá beköti a /dev/mapper-ben felvett, anno megadott alias-t, hogy a feloldott rendszer tulaja lássa, mi tartozik mihez.
Ezt egy ismeretlen, feloldás nélkül, a büdös életbe nem fogja látni.
De adok szívesen egy pendrive-ot, amire teszek ki Nektek adatot, előtte LUKS titkosítom header nélkül, próbálgassátok. Vagy még jobb, csinálok egy image-et, amit loop device-ként tudtok mount-olni és lehet nézni, mizu.
Neeeem, nem vagytok se Ti mazochisták, sem én.Értsétek meg a pofonegyszerű logikát: nincs header - nincs felismerés.
Csakis célzottan, egzakt rámutatással (ami infónak birtokában vagyok nyilván) lehet felnyitni cryptsetup-al az ilyen tárolót, én pedig pont így teszek, mert ilyenre csináltam.
És pont ez a felismerhetetlenség az, ami okozott bennem egy kezdeti törpölést, hogy akkor mi van SSD és TRIM esetén, de a választ megkaptam.
Na megyek vissza és kérdezzetek még, ha szeretnétek, kicsit nyűgös az 1080p, a 4K meg vibrál ezen a live-on
-
Dißnäëß
nagyúr
válasz
sh4d0w
#104377
üzenetére
Már hogy venné észre akármilyen random Linux ?
Ugyanazt a mozit nézzük ?
Egyik HDD-m a négyből, ez a nyers drive nézete (nem a /dev/mapper-es felnyitott ekvivalenséé értelemszerűen). Ez full disk encryption LUKS-al. Amit LUKS-ban lehet amúgy offset-elni, hogy ne a legelső szektornál indítsa, ergo akkor csak kevesebbet titkosít le belőle. Se kontroller, se más OS, se emberfia meg nem mondja, mi az a random szemét ...
A Windows ugyanezt látja és amikor a SAS kontrollert bekapcsolom (mert le van tiltva eszközkezelőben), detektálja mind a 4 HDD-t és megkérdezi, hogy inicializálja-e őket, mert tök szüzek. Nyilván cancel, különben száll minden, hiszen nem szüzek..Spéci szoftver is akkor tudja nagyjából megtippelni, hogy bármivel is titkosított a drive (úgy egyáltalán), ha a header-je rajta van az elején. Nálam ez sincs, külön vettem, akárcsak a kulcsokat, de ez mindegy is.. a header-t is tartalmazó nyers LUKS titkosított drive is tök láthatatlan azon OS-ek számára (mind számára), amik rajta kívül állnak. Lehet egy NSA-nek van féltve őrzött tool-ja ilyenek kinyitására, minthogy minden opensource kripto- és szteganográfiai projektben ott vannak (lásd backdoor), de most ezzel komolyan nem foglalkoznék mélyebben, meg ha vki rájönne, hogy van ilyen, az nagyot durranna.
Az, hogy Te hozol létre egy normál GPT partíciós táblát és azon belül egy formázatlan akármilyen partíciót, majd azt titkosítod LUKS-al, vagy mással, engedi magát detektálni - értelemszerűen, de itt szó nincs erről és nem is utaltam rá. A Windows partícióim között ott éktelenkedik a szintén LUKS-os linux gyökerem, evidens, hogy egy nemtitkosított táblában látszik, még label is adható neki, nem csak a típusa, hogy az ott adat lesz, ha tudod a jelszót..
Ember legyen, aki a telibe titkosított HDD-ről felnyalt "random adatszemétről" megmondja, hogy valódi fájlrendszer van felette értelmes adattal, pláne úgy, hogy nem írtam végig dd-vel nullákkal a /dev/mapper eszközt a mindennapi ajánlások ellenére, magyarul az alatta lévő rétegen sem írta random szarral tele a diszket a LUKS, csak ahova tényleg kitett adatot a felette lévő felnyitott rétegben (amiben olyan fájlrendszer van nyilván, amit csak akarunk, teljes értékű eszköznek látszik). Ergo, kívülről nézve egy editorból nagyjából random szemét és előző tulajtól származó további szemét és nullák váltják egymást.
Ha ugyanezt megcsinálod egy SSD-vel, addig fogja tudni a kontroller, hogy mely részein van értelmes adat, amíg a titkosítást létrehozó oprendszer erről árulkodik neki bármit is (mivel a LUKS is tud discard-ot, a biztonság rovására, de azért az sem úgy megy, mint a filmekben).
Ahogy bootolsz másik OS-el, a másik OS azt fogja jelenteni a kontrollernek, hogy "üres diszk" és amint létrehozol rajta egy partíciót (kicsit vagy telibe, mindegy), egy fájlrendszerrel, azonnal indul a trim parancsok kiadása és az SSD megtudja, hol van adat és mi a free space, utóbbit már szabadítja is fel.
Hja, csak közben belerondíthat az ott lévő "random szemétbe" ami nagyonis rendezett, semmi random, csak annak látszik. Ez HDD-n nem fordulhat elő, mivel csak akkor nyúl a fej ezen részekre, ha konkrét access érkezik ide, nem pedig üresjáratban is dolgozgat a háttérben és írogat felül cellákat, blokkokat, page-eket, akármiket, mert úgy hiszi hogy dolgozhat vele.
Amikor a Samsung SSD Magician is Overprovisioning-et állít be, lényegében egy formattálatlan nyers partíciót hoz létre a meglévők közé, jelezve ezzel OS-nek (és az meg az alatta lévő SSD vezérlőnek TRIM által), hogy az ott üres terület, lehet vele játszani. Holott fizikailag ki tudja milyen randomszemét van azokban a cellákban is, de az SSD onnantól simán felülírogatja őket, pakolgat ide-oda-amoda, wear leveling dolgozik, Neked meg ugrik a titkosított részed.
Mire ezeket bepötyögtem, megerősítettek, hogy csak úgy működik a dolog, ha nincs átfedés a látható - mondjuk - NTFS partíció és a mellé tett (láthatatlan) LUKS konténer között.
A működési elv: ha a fájlrendszer töröl egy inode-ot (vagy típustól függően hasonló logikai alapegységet), akkor a TRIM parancsot küldi az SSD-nek és informálja arról, hogy az ahhoz az inode-hoz társított adatblokkot felszabadíthatja. Mivel egy NTFS fájlrendszer nem menedzseli azokat a blokkjait egy SSD-nek, amik titkosítottak, nem is fogja azt mondani az SSD-nek, hogy szabadítsa fel azokat, kivéve ha kiterjesztem átméretezéssel az NTFS partíciót arra a területre is.
Magyarul, amíg a látható NTFS (vagy egyéb) és a láthatatlan titkosított adat egymás mellett vannak logikailag, nem lesz gond. Ha a látható átlapolódik részben vagy egészben a láthatatlanra, SSD esetén TRIM miatt kinyírja azonnal a láthatatlan titkosított részt ezzel, mert annak vezérlője a területtel elkezd "játszani", felszabadíthatónak tekinti onnantól, míg HDD esetén eljátszható simán, hogy egy NTFS partíciót kiterjesztünk rá a titkosított területre és amíg nem írunk rá, illetve arra a területre (amire nincs ráhatásunk), addig az nem is lesz bántva. Értelme nem sok, max fóbia-paranoia esetén, hisz veszélyeztetjük NTFS írás esetén a titkosított, ott és akkor üresnek látott területet, de mint megoldás működik.
Jót beszélgettünk.
-
#104371
Dißnäëß
nagyúr
tordaitibi
#104357
Dißnäëß
nagyúr
válasz
tordaitibi
#104357
üzenetére
Szerintem szétszórja. Miért ne tenné ?
Konténer itt nincs. Még partíció sem.
Tehát mégegyszer:
- Live linux
- LUKS titkosítom offset-et megadva neki az SSD második felét (vagy még hátrébbtól)
- megnyitom, lesz egy /dev/mapper/akármim és ezen partíció, majd adatok rá
- reboot, live linux usb kiBárhova viszed az SSD-t, semmi meg nem fogja mondani, hogy titkosított adat van a "második felén". Az ott kívülről random adat, nem megmondható, hogy micsoda, pláne ha még a header is máshova van téve.
Windows usb be, vagy másik Linux, mindegy.
SSD elejére feltelepít.
Bootol, minden szupi.Lejelenti az SSD-nek egy ponton a trim támogatás miatt, hogy mi az, amit ő foglal és értelmes adat. A többi mehet a levesbe.
Kontroller megkapja ezt az infót és azonnal úgy tekintheti, hogy minden egyéb, ahol nincs ezen OS által lejelentett területen adat, szemét, ergo a cellákba írhat, felszabadíthatja azokat, akármi.
Magyarul, szétcseszheti a titkosított részt akár.
Vagy nem
Erre irányul a kérdésem.
-
Dißnäëß
nagyúr
válasz
ubyegon2
#104339
üzenetére
Van ugye a Veracrypt, Truecrypt, LUKS stb.
Honnan tudja az SSD vezérlő hogy egy adott logikai szektor üres lett ? Vagy hogy az ott lévő adat "szemét" ?
Az OS lejelenti neki discard-al ?
Oké.És ha egy SDD-n egy LUKS titkosított partíciót hozok létre a 2. felére, egy Live Linuxról, az első felére pedig telepítek egy másik OS-t, amit be-bootolok, az discard-ozni fogja a második felén lévő (rejtett, nemlátott) OS-t, azaz a trim, akár OS-é, akár garbage collection, kinyírja a LUKS-os partíciót csak mert nem az őt ténylegesen feloldó-használó OS-el boot-olok be ?
-
Dißnäëß
nagyúr
Ezt nem mondtam, csak sejtem: minden kézenfekvő, tele van olyan tool-al, amivel sima floppy-t is lehet kötni a gépre és importálni be lemezeket (megfelelő csatlakozással persze), eléggé rá van optimalizálva az alap OS arra, hogy futtasson bármit és azt normálisan tegye.
+ hangulat, design, feeling, stb.
Igazából csak kipróbáltam. Mindenesetre a Streed Rod-ban jó, hogy nem kell a lemezeket forgatni 2 esemény között
-
Dißnäëß
nagyúr
válasz
ubyegon2
#104147
üzenetére
Hát, a stabilitás megkéri az árát
A stable-t sok kritika éri évek óta, hogy mennyire a "mainstream" mögött cammog (most Fedora-t nem is hozom be a vonalzó másik végéről), nyilván ára van mindennek, de azért mértékek is vannak, lehet a stabilitást is nagyon szőrszálhasogatva értelmezni és lazán is, Debianék inkább a szigorú végen vannak. Nálam nagyon bevált a testing, igazi arany középút sok téren a mindennapokban.
Unstable soha, ott futottam már bele durva csúnyaságokba, hogy nem tudtam vele mit kezdeni.
Wayland, X11, sosem érdekelt... amivel jön default a disztró, azt használom, egyedül a DE Cinnamon, mert megszoktam és nekem tökéletes.
Proprietary drivertől nem félek, nouveau is elkezdett végre fejlődni, kicsit még érik majd, adok neki egy évet aztán benne lesz már sokminden a gyáriból, amit eddig nem tudtak megoldani vele, vagy előtte körbenézek Redditen és itt-ott, mizu, de igazából ez sem érdekel annyira, a prop. driver gyönyörűen viszi az "újonnan" vett RTX3050-et, ez a lényeg.
Egyszerűen összedugom és működik, ezt szeretem benne, megy minden és elég extrém körülményeket is nagyon jól visel. Egy nagyon kiegyensúlyozott disztró.
Sok-sok kanyart tettem (anno még Suse-n voltam többet, nem is Debianon), mindennapi desktop gépként használom amúgy, azt a nagyonkeveset ami muszáj, wine-al megoldom, itt néha vannak kacifántok, amikor nyögvenyelős a dolog, akkor átmegyek W10 alá és onnan.
Nemsokára NAS lesz belőle, abbahagyom a napi ki-be kapcsolást, VGA-t is vmi egyszerű passzívra cserélem, CPU és RAM maradnak és ellesz a sarokban, építek egy új desktop-ot.
-
Dißnäëß
nagyúr
válasz
Necronom
#104041
üzenetére
GEOS istenem.... <3 <3 <3
C64 rulz.Pár hete néztem pont a Commodore OS 3.0-át (Debian bookworm alap, saját BASIC, stb). hát marha jó
Lassan már rip-elni sem kell a 120-130 floppy-m, mert minden megvan netről... durva, hol járunk technikában, anno meg csak úgy égettük a haverokkal 2 floppy-val is a Disk Copy-t, hihetetlen tetűlassú volt a legturbóbb módban is bármit megosztani egymás között -
Dißnäëß
nagyúr
-
Dißnäëß
nagyúr
válasz
Dißnäëß
#104138
üzenetére
Peru 4K kifogástalan, 175% 4K 144Hz mellett, fractional scaling controls (experimental) ON mellett. Debian 13 abból is testing, illetve Firefox ESR 128.10.1esr 64-bit, AdBlocker Ultimate + Ublock Origin + Ghostery egyszerre.
+ nvidia a kari, gyári driverrel (amit nemrég megnyitottak amúgy). De ez Cinnamon, nem plasma.
Próbáltad már esetleg ?
-
Dißnäëß
nagyúr
-
Dißnäëß
nagyúr
válasz
Adamyno
#102749
üzenetére
Lenovo mélyrepül jó ideje
Nekem is volt, adtam is el hamar.Az általános trend is gáz, forrasztott RAM modulok pl, de azt mondom, esküdnék Dell vállalati szériára, HA azokba meg tisztességes kijelzőt is tennének. Ott van még a HP, kettő vállalati is betojt alattam, kösz nem, esetleg Thinkpad-ek.. nem tudom. Nehéz.
Inkább nemvállalati noti, aminek normálisabb a hűtése, kijelző klassz, cserébe zsanérok gyengébbek, de megesküszök magamnak arra, hogy nem ejtem le
Nem egyszerű és a spórolás elvitte a vállalati "tankokat" is abba az irányba, hogy egyre több modelljük értékelhetetlen hulladék..
-
Dißnäëß
nagyúr
válasz
CPT.Pirk
#102745
üzenetére
Dettó. Új vas, GPT, haladni kell a korral. Meg nekem tetszik, hogy GPT partíciós táblán 128 partíció is lehet végre + nincs primary-secondary, csak pakolgatod egymás mellé őket, van label, stb. Annyira sokkal kényelmesebb.
Előbb-utóbb megszűnik a régi dolgok támogatása, ugyanúgy, ahogy i386-al is leállt a Debian nemrég.
Az egyetlen dolog, amitől félek, hogy a hardverek OS agnosztikussága megszűnhet.
Ma még felpakolsz bármit egy UEFi-s gépre. Holnap lehet 1 szoftver vendornak (esélyesen M$) lesz annyi ráhatása az iparágra, hogy hoz vmi olyat, amivel csak a majdani Windows fut majd minden mainstream alaplapon, vagy lesznek olyanok, amik "minden másra" is jók (pl. FreeBSD, Linux). Egyelőre nem ez az irány talán, de remélem, nem lesz igazam, csak a játékot gyakran a gigászok irányítják.
Mondjuk az tetszik, hogy Windows alá bekerült a WSL, még ha nyakatekert is kicsit, mintha megadták volna magukat a redmondiak kicsit az erő világosabbik oldalának.
-
-
#102729
Dißnäëß
nagyúr
fekete.puma
#102727
Dißnäëß
nagyúr
válasz
fekete.puma
#102727
üzenetére
/home/user/data, de leginkább - ha szokatod Magad erre, az hoz rendszert az életbe - /mnt/data például.
Aztán symlink-elni /home/user alá is, hogy ha a fájlkezelő itt indul, azonnal látszódjon
-
#102728
Dißnäëß
nagyúr
fekete.puma
#102721
Dißnäëß
nagyúr
válasz
fekete.puma
#102721
üzenetére
Gnome system monitor.
-
#102717
Dißnäëß
nagyúr
fekete.puma
#102710
Dißnäëß
nagyúr
válasz
fekete.puma
#102710
üzenetére
A konfig fájlok miatt talán.. a .-al induló rejtett könyvtárak. Kb.
Meg Documents, Pictures, Downloads, ha rendesen használod őket és sosem viszel el innen máshova (pl. NAS) adatot, jó, ha nem az OS-el együtt ül.
Nálam mondjuk így van, de én aktívan nyúzom a NAS-t is, nem csak néha mikor eszembe jut egy backup.
Szerk.: symlinkelés is hasznos, ha nem eleve amoda mount-olod fel említetteket.
-
Dißnäëß
nagyúr
válasz
sh4d0w
#102704
üzenetére
Ez messzire vezetne és nincs időm leírni, ha hétfő estig nem lesz válasz, szólj rám.
Én is ezt választanám. Olyan jó, hogy már nincs boot sector meg ilyen hülyeségek, csak legyen egy fat32-es partició benne a megfelelő fájlokkal, amit lát az UEFI (BIOS) és viszlát.
GPT partíciós tábla + UEFI-re
+1@puma: bizt kedvéért 100MB EFI system partition, swap meg ha van elég RAM, nem kell. Évek óta swap nélkül vagyok. De tehetsz neki 4G-t és később a swappiness-t lehúzni, hogy ne nagyon használja, csak ha már falnak megy a sztori (mert amúgy hajlamos írogatni bele tökfeleslegesen, alapbeállításban, az SSD lifetime pedig érték).
-
-
Dißnäëß
nagyúr
válasz
Krissz80
#102686
üzenetére
A Volumio egy komplett disztró, nem önálló lejátszó.
Lehetséges a GUI-t feltenni linuxra, ami az alatta lévő MPD-t hívja lejátszáshoz, van itt aki összetákolta ezt, de alapvetően ez egy komplett OS amúgy és még a realtime kernel-t is ajánlják hozzá (a standard helyett).
-
-
Dißnäëß
nagyúr
Sziasztok,
Minden (a szám változik)
fajl01.egyebleiras.txt -t szeretnék átnevezni
Fajl01.Egyebleiras.txt-re.És ezekből van sok, 02, 03 ...
mv -vel képtelen vagyok összerakni, még a -T sem hat, amivel a destination normál fájl lenne directory helyett, man szerint.
Van valami CLI-s nyakatekert magic, amivel össze lehet ezt rakni egyetlen parancsba ?
-
Dißnäëß
nagyúr
Uh, ezért nagy köszönet, nem reméltem ennyire részletes választ. Hálás vagyok.
lockdown90, urandom0: manuálisan kell csinálnom, bonyolítja a helyzetet, hogy LUKS-on van minden.
Tehát a boot folyamatom most kb:
- USB-ről UEFI boot
- azonnal kéri a jelszót az SSD / (root) feloldásához, ezt billentyűről megkapja tőlem, ezzel feloldódik a / ténylegesen
- crypttab-ból összeszedi a 4db HDD feloldásához szükséges infókat az SSD-ről
- header és key fájlokat felnyalva feloldja a HDD-ket kis seek-elés keretében
- boot-ol tovább és voilá, Debian Testing Cinnamon login screenSzóval igazából az SSD / -om egy /dev/mapper eszköz már eleve, így a 0. lépés az, hogy titkosítom az SSD-t, majd feloldva ezt, a /dev/mapper/ ... eszközön létrehozom a fájlrendszert, rsync ... ... ... és végül fstab/crypttab mókolás és finishing lépések.
Valahogy még összelegózom értelmesen, most munka és rohanós, csak így megjegyeztem.
Ilyen custom setup-al a Clonezilla nem bír el szerintem + én sem tanulok belőle akkor, ami célom mindemellett (járulékos hozadék) Ha elmegyek itthonról, gép kikapcs, USB kihúz és zsebre vág, aztán lehet nézelődni, mi van rajta. Egy legális W10 legális játékokkal + 4 üres HDD
-
Dißnäëß
nagyúr
Sziasztok,
a gép USB pendrive-ról boot-ol (ezen a /boot, UEFI-only konfig) és a / az SSD-n van mint egy szimpla 40 Gigás partíció.
Ha SSD-t szeretnék cserélni (mert öreg, HD Sentinel szerint már eléggé kopott, bár tünetmentes), elég ezeket a lépéseket megtennem ?
1. új SSD betesz, régi még marad
2. boot-olok hagyományos módon mint eddig
3. új SSD-n létrehozom a leendő új rendszerpartíciót, azonos fájlrendszerrel
4. mindent át-rsync-elek oda, ügyelve a kapcsolókra, tehát jogok stb... minden átmegy oda
(Itt felmerül bennem a /dev-es speciálos fájlok esete, ez így mi, hogy ?)
5. fstab-ban átírom a "root=" sort az új partíció UUID-jére
6. talán grub.conf-ban is, vagy még valahol, de nem vagyok biztos (+ egy update-grub parancs)
7. Reboot és ima.Tuti ez így nem lesz még jó, mi hiányzik ? Ezt csak a megérzésem mondatja velem
![;]](http://cdn.rios.hu/dl/s/v1.gif)
És köszi !!! 
Érdekelni érdekel, csak a mai világban már 10x meggondolom, mire áldozok időt, kevés a 24 óra. 
Nem űrtechnika, de szokni kell. 
Látható, hogy a 4db Seagate-en az égvilágon semmit nem lát, eddig ugyanaz, mint a parted. Vakon van. De hát miért is látna 
Dettó. Lehet particionálni, akármi.
Új hozzászólás Aktív témák
Hirdetés
A topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RX 6500 XT 4GB GAMER PC termékbeszámítással
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Bomba ár! Fujitsu LifeBook U757 - i3-7GEN I 16GB I 256SSD I 15,6" FHD I HDMI I Cam I W11 I Garancia!
- Bomba ár! HP EliteBook 2540P - i5-540M I 4GB I 250GB I 12,1" WXGA I W10 I Garancia!
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest