-
Fototrend
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
-
Dißnäëß
nagyúr
Kedves Szakik !
Nagyon ördögtől való fullkretén elvetemült dolog az a szándékom, kísérletezés jelleggel (egyelőre semmi konkrét adat, csak agyalok az ötleten), hogy 3 különböző szolgáltatótól bérelve VPS-eket (úgy értem, geolokáció is más lenne, de még az ország is) raid 5-öt hozzak létre virtuális HDD-kkel ?
Hmm. Lehet nem voltam teljesen világos. Máshogy mondom: 3 különböző helyszínen szeretnék adatot tárolni oly módon, hogy:
- ha egyik lokációban kiesik a VPS-em, a másik kettőről még tudjam az adatot olvasni (ezt a raid5 alaptermészete ugye adja)
- önmagában egyik lokáción se érjen az adatom semmit (ezt is adja a raid5, mert az értelmezhető adathoz minimum 2 diszk kell hozzá).Tegyük fel, gigabiten lógnak a VPS-ek, alacsony késleltetéssel, MPLS vagy IPVPN ugyan nem lesz, de valami OpenVPN megoldás igen, közöttük.
Beteg dolog, vagy pontosan ezt a fajta funkcionalitást el tudom érni más (distributed) fájlrendszerrel is, vagy máshogy trükközve ?
Lényeg tehát, hogy ha csak egyetlen VPS-be bele akar nézni "valaki" és a többiről fogalma sincs, vagy legalábbis hozzáférése semmiképp, azon az 1-en lévő adatot totál ne tudja értelmezni (a rendszeren kívül, persze, de azt nézheti...).
És akkor lenne mondjuk 3 "storage VPS"-em és egy negyedik, ami látja őket és összefogja a tömböt.
-
Dißnäëß
nagyúr
válasz
Jester01 #28566 üzenetére
A regi kis AMD Brazos eEEE PC-t az integralttal ugyanugy erinti, ez nem a Ryzen-es problema lesz sztem.
Korabbi Debian live gyonyoruen bejon.. Akarcsak a regebbi LTS Ubuntu.Vmi amdgpu kornyeken nagyon felrement az uj disztrokban
Mintha mas lenne a default es ez nem kezeli jol a VGA-kat. Csak ezt hogy engedtek stable-be, azon most is gondolkodom, en ugy kizartam volna mar testing-bol is, mint a szel. Hatalmas baki
-
Dißnäëß
nagyúr
Sziasztok, Debian 9+ AMD VGA-n elsotetul, fekete kepernyo. Eleg sok egyeb disztrot is erint a dolog. Regi kis AMD integralt GPU-t ugyanugy, mint a modernebb (ez se mai mar) RX480-amat a Ryzen konfigomban.
Bootol a motyo, aztan a desktop betoltese elott elmegy a kep es fekete semmi.
Motyognak a forumok systemd-rol, meg nomodeset-rol, stb, de ez valahogy nem allapot, hogy a tegnapi linux ment jol az AMD karikkal, az utodjai meg nem. Se regiekkel, se ujakkal. Mi a fene van itt ?
-
Dißnäëß
nagyúr
válasz
sh4d0w #28401 üzenetére
De a VGA-val van baja, nem a C50-el. Meg úgy ne release-eljünk már valamit stable branch-é, hogy az előző stable tudta. Azt megértem, ha a mostani kernel egy régi Celeron 300-on nem indul, de akkoris egy HD6250-ről van szó, H.264-et gyorsít, stb.
Betettem Elementary OS 5.0 Juno-t USB stick-en, live módban kifogástalan, szóval telepítve is jó lesz..
-
Dißnäëß
nagyúr
válasz
Dißnäëß #28399 üzenetére
Ja, az eredeti terv annyi lenne a laptoppal mindössze, hogy fejlesztésre használom a strandon. Régi, nem egy izompacsirta, de sokat bír akksival. Távoli asztallal bemegyek az itthoni asztalimra és tolom a dolgot szépen, ennyi.
Esetleg egy céges email nézés, böngészés (nem youtube), ilyen alap dolgok.
Nem várok sokat egy Debian stable-től, csak annyit, hogy mainstream gyártó mainstream video chipsetjén adjon már képet könyörgöm. Ez nem egy S3 Trio, vagy urambocsá, Matrox Mystique.
-
Dißnäëß
nagyúr
Sziasztok, Debian hozzáértőktök érdeklődnék, hogy vajon hogyan engedték ki a Debian 9-et stable-re, ha bnőm ASUS EeePC-jén a Radeon HD6250, ami 8-as Debil alatt gyönyörűen támogatva volt, 9 alatt fekete képernyővel fogadja az embert ?
Ez most komoly, vagy esik szét a Debian közössége (és szoftvere), vagy mi történik ?
Értem én, hogy firmware-amd-graphics meg a kernelbe betették a támogatást a 9-essel, meg egyéb finomságok, ez mind
szuper és jó(vagy sem).De ez akkoris egy stable kiadás kellene hogy legyen, számomra nem lenne megengedhető akkora mértékű BUG, hogy a világ Radeonos gépeinek bizonyos hányadát érintse. Ez nem egy stable-ben megengedhetően bennmaradt (vagy benézett) bug, hogy most az XY réteghardver streamer nincs jól kezelve, vagy valami elhasal, eltörik, egy Radeon GPU eléggé mainstream-nek mondható. (Esetemben AMD C50-es prociba tett HD6250, de erre a hibára rákeresve a teljes Debian-Ubuntu vonal ettől hangos, különféle 6-7-es szériás Radeos user-ektől).
15+ éve használok Debiant, anélkül, hogy belemásznék a fejlesztésbe, filozófiába, bármibe komolyabban, szerintem ehhez egy emberélet kevés, de a minősége kicsit torpanni látszik, legalábbis számomra. Használok stable-t is, testing-et is próbálok új gépen szívesen, de egy kis EeePC-n, amire a Win7, Win10, Debian 8 felmegy csont nélkül, a Debian 9 elhasal, a Live sem jön be (bejön, csak no kép, mert pingre válaszol).
Aztán jönnek a grub betöltő sorok szerkesztése, nomodeset javaslatok (ami nem működik, mindaddig, míg az acpi=off és/vagy a nolapic mellé nem kerül), firmware-amd-graphics telepítése és hasonlók, reboot és ugyanúgy black screen. (ssh-n persze elérhető marad helyi hálón).
Valahogy össze fogom szarakodni, hogy a 9-es is menjen rajta, a gondom inkább az, hogy így lett stable a 9-es, hogy egy mainstream-nek mondható hardveren nonstop történik valami szar és kezd az összes tököm kilenni az egész Debiantól. Korábban a wifi firmware-ek körül ment ez, megértem én a háttérokokat, gyártók genyók, satöbbi, lehet sok irányba mutogatni, de akkor sem ideális szitu. És most csak kipuffogtam magam, megoldást nem várok feltétlen, de rohadtul fel tud *ni..
Alternatív disztró esetleg ? Próbálok most egy Elementary OS-t, hátha.
Csak semmi kedvem leszokni az apt-zésről és valami mást megtanulni, pedig lehet, hasznomra válna.
Még egy Mint-et ráeresztek, csak a teljes Ubuntu line-tól és annak származékaitól (amik végeredményben agyon-tweak-elt Debian testing-ek) fázok
-
Dißnäëß
nagyúr
válasz
Frawly #28389 üzenetére
Valid az is amit írsz, de nekem kicsit minden amolyan tanuló challenge is, kihívás. Néha nincs értelme, vagy túllövök a célon, de tanulok általa (ami általában szívás, de hát ez van). Az észrevételeket köszi, igen, SSD titkosítást használtam korábban, földi halandót megakasztja, egy sznóden 2 viszont lehet, tudna meglepőt mesélni az "irodából"
Gyanítom, van kiskapujuk hozzá. (Mondjuk nem érdekel).
-
Dißnäëß
nagyúr
válasz
bambano #28387 üzenetére
Van a hdd-n part. tábla, csak a titkosított részen belül.
Kívülről, az usb stick nélkül boot-olt W10-el (vagy Ubuntuval) ez nem látszik, hiszen random adat van ott neki a HDD-n.
Ha viszont USB boot-olok a pendrive-al, a random adathalmaz hirtelen értelmet nyer, a LUKS header is itt van és a kód beírása, a rejtett rész feloldása után a virtuális (dekódolt) meghajtón ott lesz a partíció, ami persze már elérhető a Linux OS-nek innentől.
Egyébként kicsit a Veracrypt dolgozik hasonló (ennél szofisztikáltabb) módszerekkel, de erről is anno találtam egy tutorial-t, hogy kézileg hogy lehet egy ilyet összehozni.
-
Dißnäëß
nagyúr
válasz
MrCsiT #28385 üzenetére
Még nem másztam bele komolyan, de Ubuntu Server elvileg tud ilyet: snap-eket kell telepíteni az egyes Linux virtuális gépekbe (vagy konténerekbe) és a snap-eken keresztül képes vagy őket managelni, app-okat telepíteni, eltávolítani, verzió kontroll, frissítések, stb stb.
Ha ezt körbeguglizod, vagy magán az Ubuntu Server oldalán kicsit körbejárod, meglesz, amit szeretnél.
De aki már mélyebben foglalkozott ilyesmivel, lehet, majd itt segít..
-
Dißnäëß
nagyúr
válasz
sh4d0w #28382 üzenetére
Ez amúgysem lenne dualboot, nem az a cél
Ha beindítod a gépet az USB stick nélkül, egy 60 gigás C: partíciós Windows (vagy Ubuntu, mindegy) fogad és a HDD maradék részén még partíció sincs. Ha akarsz, létrehozol ott valamit, D: , stb ... klasszik módon (Windows-nál maradva például) és ollé, használod.
Ha ugyanezt a gépet viszont én a kis "nyakbaakasztós" Sandisk Cruzer Mini-mről boot-olom USB boot-al, betölt egy olyan Debian, aminek /boot -ja maga ez az USB stick és LUKS header-től kezdve maga a LUKS titkosított /root (és minden egyéb) motyó a HDD azon szektoraira esik, amik a Windows általi rendszerben nem is látszanak, mert annak random értelmezhetetlen adat, míg az USB-ről boot-oló Linux természetesen "tudja", hogy ott mit keressen, megtalálja, feloldja és használható. (Kellő körültekintéssel, pl. /boot-ot újra mount-olni, hogy USB eltávolítás után is mint olyan, létezzen, valamint kernelt érintő változtatások, update-grub és társai esetén az USB stick-el összhangba hozni, sync-elni, de ez alap).
Szóval.. ez nem dualboot. (Bár amúgy a felvetés jogos, az USB stick-ről boot-olt GRUB ha felveszem, indíthatja a Windows-t is, ha nagyon akarom, de nem fogom akarni).
-
Dißnäëß
nagyúr
válasz
Plasticbomb #28380 üzenetére
Igen, csak titkosítást tudó SSD-im vannak, de nem használom - még. Itthonra minek.
Amúgy paranoia, igen, csak távoli gépről (szerverről) van szó, ott meg nem szívesen hagyok csak úgy akármilyen adatot. Egyébként relatív egyszerű dolgok ezek.
HDD-t fogok használni (már csak a méret miatt is), az SSD oldala csak érdekelt puszta kíváncsiságból, de szerintem nagyjából megválaszoltad a kérdésem.
-
Dißnäëß
nagyúr
válasz
ubyegon2 #28378 üzenetére
Ezt meg én nem biztos, hogy értem, de próbálom..
Amit én mondtam, annyi nagyjából, hogy titkosítanék egy nagy HDD-t, amire kerülne egy Linux alaprendszer és egy raklap fájl, a fontosabbak backup-olva vannak máshova is, sync-elődnek egy távolabbi géppel, stb.
USB-ről boot-olna a Linux, majd ezt kivenném a gépből boot után és hadd menjen enélkül.
Ha leállítják, ellopják, akármi, amikor beindítják, ugyebár töküres gépet találnak, tök random adattal a HDD-n (ami lényegében ha így nézzük, nem adat, vagy legalábbis nem értékelhető számukra)
Senki nem fogja semmiből sem tudni-sejteni, hogy a HDD nagyja egy titkosított terület.
Viszont így még mindig tarthat bárki a fejemhez pisztolyt, hogy oldjam fel.
Egyszerűbb elterelni egy rabló figyelmét azzal, hogy mondjuk egy 8TB-s HDD-ből beáldozok pár gigát az elejéről egy klasszik Windows telepítésre, ami bár nem használja a HDD többi részét, rá lehet fogni, hogy frissen telepített rendszer, stb, bla bla, akármit, jön a mese és már nem azon kattog senki, hogy esetleg az első 60 Gigás partíció mögött indul egy egyébként LUKS-al és az USB kütyüvel a Linux számára igenis látható-értelmezhető adatpartíció, amit feloldás után használok is szépen.
Szóval örök és hiperszuper titkosítás nincs, nem létezik, viszont figyelemelterelés igen. Ezt még jobban lehetne egyébként szofisztikálni, de már ennyi is elég nekem, hogy első 60GB egy oprendszer, mögötte pedig csak az mondja meg, mi van ott, aki tudja ténylegesen, mi van ott. A többiek csak büdös nagy semmit látnak (=random értékek a szektorokban).
Egy HDD-nél nyilván amíg az első 60G-re telepített oprendszer nem ír bele a maradék üres területbe - és miért is tenné - nincs ilyen gond, a kérdésemnek nincs is létjogosultsága.
SSD-nél más lehet a helyzet, nem tudom, hogy egy összevissza adatokkal teleírt területet, amit nem particionálok, amúgy bevon-e a vezérlő a wear levelingbe, beleírva azon területekbe.
Szóval SSD és trim esetén nem tudom, az első 60GB fizikailag mindig ott marad-e ugyanazokon a memóriaterületeken, vagy "vándorol", ahogy bizonyos blokkok íródnak, felszabadulnak, újraíródnak, újra felszabadulnak, stb stb. Ehhez a részéhez nem értek egészen, nem tiszta számomra, ráadásul belsőleg is végeznek bizonyos SSD-k (hacsak nem mind szinte) wear leveling-et és az OS részről is.
De ha valaki annyit mond, hogy SSD esetén is működik az, hogy a partícionáló programból (legyen egy W10 telepítő) az első 60G-re W10-et teszek, majd a szabad területet egy Linux titkosított partíciónak használom, ahol még a partíció fejléce, mindene cakkpakk titkosítva van, akkor ma este jól alszom.
-
Dißnäëß
nagyúr
Sziasztok,
azt szeretném megvalósítani, hogy USB-ről boot-olok, LUKS header is erre kerül, ergo a HDD totálrandom adattal van tele és csak az USB-ről boot-olva töltődik be a rendszer úgy, hogy a "random" adathalmaz feloldódik (titkosított partíció).
Viszont !
Csinálnék a HDD-re egy "kamu" rendszert is, valami sima desktop telepítést (Linux/Windows akármi), beáldoznék rá egy 60G körüli helyet. Az emögötti területet a sokterás HDD-n ez a kamurendszer nem látná, nem lenne számára se particionálva, se semmi - értelemszerűen, hiszen neki ez csak random adat.
De amikor az USB kütyüről boot-olok a Linux-al, akkor ott nyilván feloldás után látszik az első ~60G utáni "random" tartalom is (ami egy óriási titkosított egybeterület kb, amit már a linux alól úgy kezelek logikailag és arra használom, ahogy csak akarom).
Namost ezt mind szép és jó egy HDD esetén, de mi van, ha SSD-ről van szó ?
- Egy trim közbeszólhat és mondjuk az első 60G-s partición lévő Win10 ha boot-olt és zajlanak rajta a műveletek, használgatom is kicsit, stb, a mögötte lévő, számára random adatot tartalmazó particionálatlan területet lejelentve az SSD-nek üresként, oda is ír a wear leveling vajon, szétcseszikélve az én kis ott lévő titkos blokkjaimat és szektoraimat, avagy sem ? -
Dißnäëß
nagyúr
Opera senki ?
-
Dißnäëß
nagyúr
válasz
Frawly #28187 üzenetére
Ez lesz. Bár igazság szerint inkább csak a kihívás miatt - illetve hát privát családi fotók, hobbi fotósként tele vagyok RAW fájlokkal, szép emlékekkel, kigyepáltam már rengeteget, de hát így is maradt, 8 éve gyűlik..
Szóval nekik valami "redundáns" megoldást keresve agyaltam egy raid1-es tömbön, bár logikai hiba (félrenyomok és törlök) ellen nem véd, de valahogy mégis megnyugtat.
Amin még agyalok, hogy egy másik lokáción elhelyezek egy kis mini gépet vmi linux-al és arra át-sync-eltetem a fájlokat rendszeresen. Nálam most lett 1000-es Digi, anyámnál meg szintén elérhető ott, ahova most költözik pár hónapon belül és akkor lenne a pincében egy kisfogyis mini ITX kütyüje benne egy X terás HDD-vel, első sync SATA-n a gépemben, aztán leviszem hozzá a kütyübe az egyik vinyót, rendszert telepítek, kis szoftver konfig és ollé.
Így ha magamnál bármit elcseszikélek, ott még mindig meglesz.
-
Dißnäëß
nagyúr
válasz
bambano #28183 üzenetére
Ahh sry, éjjeli nagy-release-eltünk élesen, már nagyon zombin írtam.
igazán alaposan azzal tudod lerontani a teljesítményét, ha nem illeszted 8 szektoros határra a szektorokat
Mármint a partíciókat, nem ?Deee amúgy értelek, de ezeket elvileg automatán kezeli már fdisk is, parted is, meg ezeknek a gpt megfelelője is.
Mindenesetre kicsit még utánaguglizok ennek és akkor jó lesz. A lényegre választ adtál, én sem gondolom, hogy probléma lenne hellyelközel hasonló sebességű két eltérő drive között tökazonos méretű partíciókat md raid-be fogni. Ez így ideális lenne nekem biztonságos tárolásra a privát cuccaimra (raid1) + a maradék helyekre amíg-ahogy fér, úgy másolok.
Lenne még egy kérdésem: OpenVPN megoldások. Az ASUS router-em tudja, szerver és kliens oldalt egyaránt. Kulcsot mivel generálok a konfigba neki ?
Ezekben a cert-es kulcsos dolgokban sosem másztam bele mélyebben. A router lenne a fogadó fél, amibe 2-3 W10/Linux kliens hívna be ad-hoc jelleggel, illetve haverom szintén félokos-routere állandó jelleggel (site-to-site).
-
Dißnäëß
nagyúr
Sziasztok,
ha raid-ezni szeretnék, mennyire érzékeny a softraid-ezés a különböző méretű meghajtókra, byte/sector-okra, stb ?
Például ha nem egész meghajtót használnék raid-ben, csak mindkettőn lenne egy 1T-s partíció, amiből kreálnék egy raid1-es logikait, a többi hely pedig mindkét drive-on maradna önálló, direktben elért motyó.
Egyik mondjuk egy 4T-s HDD, másik egy 2T-s, egyik Advanced Format-os (4096 bytes/sector), másik nem (512 b/s), egyik GPT, másik MBR típusú ..
Szóval simán mdadm-ből megalkotom mondjuk az md0-át és kész, voilá, vagy feltétlen muszáj bizonyos korlátokat betartanom, elfogadnom ?
-
Dißnäëß
nagyúr
Esetedben Te bal lentről indulsz, localhost-ról, local process-ből és felfele haladsz.
Az OUTPUT több táblában is szerepel, tábladefiníció nélkül megadva a filter táblában lévő része van értelmezve és annak megfelelően ott machinálsz.
A baj ott lehet, hogy X user kimenő csomagját ha Te VPN-be akarod áttolni és ez magáról a tűzfal gépről származik, ami ha jól értem, így van, azaz localhost-ról származik a csomag (!), akkor a filter tábla OUTPUT láncán átmegy, abba meg betettél egy DROP-ot, persze, hogy fogja.
Kiszedném ezt a DROP szabályt és inkább egy ilyen UUID-el létrehoznék OUTPUT-ban egy ACCEPT szabályt, DROP-ot pedig nem is tennék a lánc végére, szerintem kevésbé szerencsés megoldás, inkább a lánc policy-jét érdemes DROP-ra állítani és automatikusan dob mindent, ami nem felelt meg 1 szabálynak sem (vagy még mindig a láncon maradt).
Ha a szomszéd, melletted lévő gépről jönne a csomag és így kéne mennie tovább másik interfészre, akkor a csomag kihagyja localhost-ot és source/destination nat mellett machinálni a FORWARD láncokkal is, azokban szűrni (mondjuk policy DROP-ra itt is és akkor ütsz a pajzson egy lyukat, de az alapvetően mindig dob mindent, illetve a vissza iránynak is a válaszcsomagok érdekében ütni egy ACCEPT-es szabállyal lyukat és szűrted az átmenőt is). FORWARD-nál arra érdemes ügyelni, hogy kétirányú, tehát ott van -i és -o is értelmezve, míg egy INPUT chain -o eth0 -ra például elhasal, akárcsak egy OUTPUT a -i -re.
Itt mégegy.
-
Dißnäëß
nagyúr
válasz
Mr Dini #28035 üzenetére
Hátha ez segít, a sorrendiség fontos. Alapból ezeken az "állomásokon" mennek át a csomagok, iránytól függően, illetve nyilván default-ból minden nyitva + amikor csak chain-t nevezel meg, tábla nélkül, akkor az a filter táblán operál (mindaddig, míg az adott lánc filter-ben értelmezett, például PREROUTING lánchoz hiába adsz szabályt hozzá filter-en, hibát dob, ő a nat-ban és a mangle-ben értelmezett).
Egyébként meg igen, a szabályok egy adott chain-en belül sorrendiség alapján haladnak előre, szabályról szabályra vizsgálja a kernel, az adott szabály érvényes-e a csomagra, ha igen, annak megfelelően kezd vele valamit, ha nem, lépteti a következőre. Ha egy szabály sem illett a láncban egy adott csomagra, a lánc policy-nak megfelelően dobódik, vagy kikerül a láncról, vissza a fő láncra, ahonnan meghívódott a "custom" (saját) lánc.
Mint egy futószalagon és ami csomagra érvényessé válik egy szabály, azt leveszi a "futószalagról" és már nincs rajta többé (kivéve mondjuk egy log-olós szabály lánc, ami a log-olást elvégzi úgy a csomagra, hogy közben a csomagot nem mozdítja el erről a futószalagról).
Én amúgy sosem támogattam a DROP-ot, szerintem sokkal biztonságosabb és emberi hibát elkerülőbb, ha nincs DROP-od a lánc végén, ellenben a lánc policy-jét állítod DROP-ra. Valahogy butabiztosabb, de ezt csak lezárásra értem, ha menet közben kell okkal DROP-olni valamit egy viszonylag megengedő láncban, jó a DROP.
Egy piszok egyszerű ultraalap mókán szemléltetve:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P INPUT DROP -
Dißnäëß
nagyúr
Még nem vettem meg a két pendrive-ot, a Media-ban kicsit sokallottam + nem találtam olyat, ami kulcstartózható vagy ilyesmi. (Egyik backup lesz otthon, másik tényleg kulcsaim között).
Nézek online. Utána telepítem újra.
Egyébként ha már LUKS2 a merevlemezre: az utolsó bit-ig random, ha rendesen LuksFormat-ozom telibe random adattal, stb.. ? Arra gondolok, hogy egy ezzel a módszerrel titkosított háttértáron még fejléce sincs a titkosításnak, igaz ? Szóval kvázi totál megállapíthatatlan, hogy titkosított-e, vagy tényleg csak random szemét van-e rajta ?
Én az utóbbira voksolnék, nincs fejléc sem, mármint ami nemtitkos, szóval avatatlan szemnek és hozzáértőnek egyaránt egy nagy random használhatatlan szemét, ami kívülről látszik, igaz?
-
Dißnäëß
nagyúr
Egyelőre én is így gondolom. Lehet egy (már titkosított logikai) /boot partíciót létrehozok és minden rendszerindítás után erre másolom át a pendrive /boot-ját (ha szükséges, frissítés után stb). Csak a biztonság kedvéért. Néha meg ránézek, egyeznek-e (ha nem csináltam update-et, de minden frissítés csak kézi, szigorúan, tehát elméletileg nem fog önálló életet élni és /boot-ba nyúlogatni az apt).
Köszi a visszajelzést.
-
Dißnäëß
nagyúr
válasz
Dinter #27970 üzenetére
man oldalakból most gyorsan:
-m reserved-blocks-percentage
Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-
owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from
writing to the filesystem. The default percentage is 5%.Legalábbis ext3-ra írja talán, úgy látom.
+ journal, egyéb overhead.. de a nagyja sztem a fentebbi.
-
Dißnäëß
nagyúr
Sziasztok,
adott egy szerver (most kérek mindenkit, ne lamentáljunk azon, hogy mi az a szerver)
, ennek van egy titkosított HDD-je, és külső pendrive-ról boot-ol (tehát a /boot is itt).
A pendrive-ot szeretném a zsebemben tudni, a nyakláncomon, illetve a csuklómhoz láncolva.
Szóval: megtehetem azt bármilyen konzisztencia-sérülés ill. rendszerleállás nélkül, hogy a /boot-ot boot-olás után unmount-olom, vagy elég /boot-ot létrehoznom a gyökér fába és bemásolni rá a pendrive /boot tartalmát ?
Természetesen minden update-upgrade kézi, tehát mielőtt futtatok esetlegesen a /boot-ba feltehetően író parancsot, script-et, a pendrive-ot bedugom és mount-olom az igazi /boot-ot.
Szóval kell tükröznöm-trükköznöm, vagy hogy is van ez ?
-
Dißnäëß
nagyúr
válasz
0xmilan #27962 üzenetére
Köszi.
Egy ideje már nincs kedvem leállni magyarázni a miért-et, ha kapok hogyan-t, kapok, ha nem, nem. Látom, Neked még van türelmed hozzá
Egyébként megoldottam, találtam GUI-t, amivel kapcsolódok a futtatott daemon-hoz, így nem kell Xming-el és putty-al mókolnom (ami a válasz lett volna amúgy, kipróbáltam, tökjó).
-
Dißnäëß
nagyúr
Sziasztok, vettem egy kis VPS-t hobbi célra, Debian, totál alap install (Testing). Tennék rá egy Xfce desktopot, amit ssh-n keresztül telepítenék úgy, hogy mivel nincs grafikus felületem, nem tudom, egyáltalán meg lehet-e lépni és mûködne-e.
Ha megvan, valami "távoli asztal" megoldással lépegetnék be rá ssh tunnelen keresztül itthonról (putty-al).
Hogyan telepítsem kb ?
Célom az, hogy amikor kilépek belôle, akkor is fussanak tovább a grafikus felületen a progik, mintha csak a monitort kapcsolnám ki, ha fizikai gép lenne.
-
Dißnäëß
nagyúr
Utolsó kérdés mára és nem fárasztalak Titeket
1. Egy 250-es SSD-n van most W10 is (C: és D: ) illetve utolsó partíciók között egy Linux telepítés is.
2. Van egy 120-as SSD-m is.
3. D: elég nagy, nem kell. Így beférnék a 120-asra simán, 1:1, a rendszer (és sallangjai, a kis partíciók) partíciókkal.
4. HOGYAN ?Hogy boot-oljon is. Most GRUB van természetesen. 10 éves AM3-as Gigabyte lap, nem EFI.
Régen ezt ilyen Paragon Partition Manager-ből kreált Recovery CD-vel oldottam meg: boot, összekattintgat, ha minden oké, nagy piros gomb megnyom és a program elvégzett minden módosítást.
Elég az is, ha ajánlotok hasonlót (akár ugyanezt, a friss verziót, akár egyebet, ami képes partíciók mozgatásával, nem 1:1 leképezéssel áttenni két rendszert egyikről a másikra). A partíciók mérete változna csak, sorrendje nem (bár ha D:-t gyepálom, lehet beleszól, a W10 előtte van, a Linux mögötte).
-
Dißnäëß
nagyúr
válasz
sh4d0w #27746 üzenetére
Teljesen igazad van. Csak nem mindegy, hogyan dobom kukába. És kislabdadobásból is sajnos mindig feketepontot kaptam.
Egyébként léteznek alternatív megoldások, legalábbis google alapján smartctl, TLER, CCTL, ddrescue (de én írnék), eh_timeout, hdparm, ilyesmi progik és paraméterek környékén.. de ahogy látom, TLER menti meg sokak életét.
Azért köszi, egynek bedobtam. Összerakom.
-
Dißnäëß
nagyúr
Sziasztok, újra én. Úgy látszik, problémamegoldós hétvégét ütemeztem be magamnak
1. van egy néhol jó, néhol kevésbé jó HDD-m. Szeretném törölni. Milyen eszközzel vagy paranccsal tudom úgy teleírni random adattal (de lehet tőlem 0 is), hogy a problémás szektorokon ne álljon le lassúzni, próbálkozni, erőlködni, hanem ha instant nem megy, skip, átlépte, annyi, megy a következőre.
Se a HD Sentinel Windows alatt, se a DD linux alatt (zero-ból vagy urandom-ból) nem képes erre, beleállnak a rosszabb szektorokba, elpöcsölnek, végül sikerül és tovább lépnek - a következőre. Sebesség leesik a béka se**e alá nyilván.. aztán újabb jó rész következik és újra szárnyal az írás.
Gyanítom, ez valami low level paraméter módosítást igényel, hátha Linuxban van erre megoldás (friss Debian Testing-em van). Szóval a vezérlő (?), kernel (?) ne erőlködjön: ami nem megy, skip, maradhat úgy. Ennyi a lényeg. (És akkor randommal írom, ez már eldőlt).
-
Dißnäëß
nagyúr
Hát ez nagyon gyors volt. Köszönöm, hibátlan válaszok
(fstab-ba inkább UUID alapján kötöm, de a paraméterek hasznosak voltak).Apropó, ntfs mount esetén "defaults": nem kell discard ? (ssd..)
-
Dißnäëß
nagyúr
Sziasztok, a kezdőben azt javasolták, itt kérdezzek. Jöttem
1. Ha többféle HDD-m van többféle méretben, mindenféle raid-eket alkotok (alsóbb szinten), majd ezeken felül teszek-veszek, néha át akarom konfigolni, fájlrendszert csökkenteni-növelni, ilyesmik -> LVM ?
2-es kérdés - kicsit egyszerűbb: JBOD-t használ valaki ma még, mondjuk bukható adatra, vagy csak a múlt egy csúnya csontváza és LVM mellett értelmetlen, vagy mi van ezzel most ? Újra megszerezhető anyagokat JBOD-zzak, vagy szimplán 2 HDD-n keresztülívelő LVM volume-ba tegyem ? (Esetleg a gyorsabb transzferek érdekében raid0, nem gond ha buknak.. de ha nem raid0 ?).
3. Debian alatt az NTFS partícióimon a karakterek nincsenek jól kezelve. Pár ékezetes helyén kérdőjel. Friss install, friss testing telepítőről (nem ez a gond sztem). Mount-olásnál kellene ráerőltetnem valami UTF-8-ra ? Gondolom vmi egyszerű kódolás értelmezési dolog lesz.
-
Dißnäëß
nagyúr
Értékelem a második értelmes hsz-t a témában, de nem is várom el, hogy mindenhez értsen mindenki. Elég, ha a torta egyik szeletéhez egyikőtök ért, a másikhoz más, az viszont biztos, hogy ha én fél-noob-ként látom-tudom, hova mi kellene (lehet alábecsülöm magam?) , ergo lehet látom az egész tortát, akkor Ti is , garantáltan.
Nem kell minden egyes szeletéhez érteni profin mindenkinek.
VPN haverral ? Nem kell semmi extrára gondolni: Windows alól szeretnénk használni egy internetet nem route-oló VPN-t, régen IPSEC/L2TP kettős konfig, most már Strongswan/Openswan vagy mi megoldja IKEv2-vel az egészet, úgy tudom, de mindegy is, szóval kapcsolat indít kliens oldalról és miközben haverom a fülemen és beszélgetünk az egyik webshop-unkról egymástól 50km-re 1-1 headset-el, tudom neki azt mondani, hogy a "közösről" nyissa meg XY fájlt, beleírtam amit kell, bla bla. Ennyire egyszerű dologról beszélek, ez egy VPN kapcsolat (felőlem natívan W10 alól vagy OpenVPN), egy SAMBA, némi tárhely (pár giga) és kis konfigolás, amit rábíztam volna egy webes akármire, amit SSH Tunnel-en érnék el, semmi nagyvilágba kitettség, és jónapot.
Ez ennyire bonyolult ? Összerakom tutorialból - 1 nap.
Összeraknám egy jó webes admin felülettel - 15 perc.Hülyézni játékkal ott a Hamachi is, akkor nem írnék le ilyesmiket.
A többi céltevékenység dettó. Minden fél nap, 1 nap, satöbbi. Nekem elég a logikáját megérteni a dolgoknak, nem fogok/akarok konfig fájlokat túrni, mert míg az iptables scriptelés marhára érdekel és imádom, és vért izzadva is szénné tanultam, addig mondjuk pontleszarom, egy Apache vagy Nginx konfig hogy épül fel, csak gyorsan belőném, legyen viszonylag secure, gyors és kész, jónapot, hagyjon békén.
Nem kell a tortának minden szelete.
Na meg van magánéletem, van barátnőm, van tervem fotózásra, Photoshop, stúdióba menni fehérneműs szettet fotózni, MILC-ezni, kirándulni, szívemcsücske autóját ápolgatni és még n+1 olyan dolog, ami nekem nem fér bele a 24 órába -> ismét egy ok a webes admin csomagok egyike mellett.
Nem 18 vagyok már, hogy suli után 2-től függöm a vasat, anyám ha szól, rush-olok egyet a konyhába 2 perc vacsira, aztán vissza a gép elé és éjfélig függés.
Haladjunk, kiásom magam.
-
Dißnäëß
nagyúr
válasz
Frawly #27047 üzenetére
Mindenképp vt-d-s i-vel dolgoznék, i5 v i7, AMD vonalon meg Ryzen. A webes felület azért gondolkodtatott el, mert két hosting-nál is cPanel volt és annyira tökjól tette a dolgát mindenféle beállításban, bármit változtattam, hogy azt mondtam magamban, wow, ez klassz, jól kiforrta magát. Emlékszem, milyen volt a Webmin 10 éve - kalap szar. Lehet ma is, nem én akarom ezt itt kijelenteni, mivel nem követtem. Lehet, ennél a két hostingnál a cPanel nem a gyári volt, hanem hülyére bugfixelt saját kézzel kikalapált találmány (ergo, a gyári default cPanel köhögős, de a a szkripteket helyre teszik alatta, jó lehet).
Igazából annyi van csak, hogy nálam nem minden fekete fehér és nincs olyan, hogy full szar, vagy nemszar. Amin dolgozik az ember rendesen, az előbb utóbb összeáll.
Matekoltam itt az időm, hogy most akkor helyi virtuális háló a host-nak, arra tűzfal dolgokat stb. beállítgatni, egyik gép natolva, másik nem, csak egy transzparens proxy, helyi DNS és DHCP kiszolgáló setup, ftp szerver, SAMBA szerver, szinkronizáló script-ek, rahedli crontab mókolás, hogy mikor mi fusson le néha, aminek értelmét látom, SQL, webszerverek, stb stb, áhhh.
Nem akarom 40 évesen még mindig a nulláról magam keverni a betont, inkább hozatok transzportbetont, pontalap, lefúrják a földbe, áthidalók, falak és áll a ház. Kb.
Sokkal jobban érdekel ma már a logikai felépítése a dolgoknak és magasabb szinten agyalni, mint ultraminimál szinten konzolban túrni már megint az ezredik conf-ot. Jobban izgat azon kattogni, hogyan hozok össze milyen magyar törvényeknek is megfelelő számlázót a webshop engine-emmel, mint már megint valamelyik konfiggal hajat hullatni és úgy reméltem, nyerhetek működő, automatizált script-ekkel némi időt.
De nem, áhhh, megyek Windows-ra
Sziasztok.
-
Dißnäëß
nagyúr
Á nem, kösz, inkább Windows. Egy nagyon konstruktív kolléga azt mondta, hiszek a jóindulatában, igazi lelkes jóakaratú magyar, szeretem az ilyet.
Szerintem semmi nem ment át abból, mit akarok. (Hogy ki miatt, hagyjuk, simán vállalom egyébként).
Eddig amúgy nonstop ssh-n túrtam végig és még a tűzfal is saját volt, legalábbis a csomagszűrő része.
Van egy Core2-es laptopom, pont 20-at ér, 4G-vel, most Ubuntuval. Egész jó, mondjuk az Intel GMA egy hulladék benne. De hogy ezt kéne betennem egy DC-be, izé
Köszönöm, köszönöm, szuper topic. Csak így tovább !
-
Dißnäëß
nagyúr
Sziasztok,
jó kis miniflame vagy inkább agyalás megy itt frissesség stb. ügyekben.
Próbálgattam az évek alatt nem egy VPS-t, volt, amelyik jó volt bizonyos célra, volt, amelyik kicsit lassúcska, hiába volt közel hozzám és jó sávval, szóval még mindig a dedikált szerver hasít a legjobban. Legalábbis volt vagy 2 évig egy dedikált négymagos desktop vasam anno a Victor Hugo-ban, nagyon stabil volt és a saját 6-8 VPS-em is rajta tök jól mentek, klassz sebességgel, szerettem. Gigabyte alaplappal, sima otthoninak épült vas, semmi HP/Dell/Supermicro meg ECC meg ilyenek. De ez "régen" volt.
-------
Erre a szerveresdire keresnék valamit, a tanulás is vezérel, éles cuccot nem tennék rá egyelőre (és ha igen később, azt normális szerver vasra, HA konfigban, nem otthoni célra szánt ASUS-ra).
OS-re lövök, de nem szeretném az egész életem VM-ek, Clusterek és ilyesmik nyomkodására "elpazarolni" , szóval valami webes control panel felületet is szeretnék hozzá.
- CentOS ? + cPanel ? (de ez tudtommal csak konténerekig megy, OpenVZ kernel, én meg ennél lehet, jobban akarnék szeparálni)
- Debian + Xen Project ?
- Bármi egyéb ajánlás ?Illetve a mágikus kérdés, hogy stabilitás vs. frissesség - host szempontból nézve, ami több teljes értékű vagy félpara vagy para vagy konténert lát el, mennyire érdemes a frissesség paraméterre gyúrni ? A túl friss disztrókban és csomagokban lehetnek még ki nem derült bug-ok (valószínűbben előfordulva legalábbis), míg túl öreg disztró és csomag szett lehet, a hardvert nem szereti majd.
Továbbá nem hardcore, inkább tanulás jellegű még mindig a dolog, ennek fényében egy desktop Ryzen konfig mennyire lehet életképes ? Ez a sok fizikai mag ahogy jön lefele lassan földi halandónak is elérhető ársávba, tetszik.
Egyelőre rahedli hobbi cuccnak szánnám a gépet. Hosting-olni ezt-azt, közös tárhely haverommal VPN-en keresztül, email hegyek több domain-el, hobbi oldalak, mittomén, mindenféle ökörködésre, ami által közben mélyedek ebbe-abba, mikor mibe.
Meguntuk a felhőket, tiszta ég jön. Hozzuk át a domain-eket is GoDaddy-től svájcba, konszolidálunk, tisztogatunk, van mit.
-
Dißnäëß
nagyúr
válasz
Frawly #26993 üzenetére
SSD-t tikosítom, a saját megoldásával, amit Te is írsz.
Egyébként törni nem lehet, de újra lehet firmware-elni az SSD-t, az adathoz természetesen nem férsz hozzá, azonnal buksz mindent, viszont a meghajtót egy üres, pucér SSD-ként lehet használni. De ez meg már mindegy az adatok védelme szempontjából, mert ha a strandon vagy mittoménhol laptopozok és ellopják vagy elhagyom, nem szivárog ki semmi, ez a lényeg. A backup van-e már más kérdés.
A legújabb Debil alatt csinálom, 9.5 stable. (Mivel stable, nem tekinthető a legújabbnak)
-
Dißnäëß
nagyúr
válasz
bambano #26991 üzenetére
Világos.
Egyébként érdekes, hogy Te is az utánad érkező is azt feltételezi, hogy én nem akarok kézzel beírni jelszót. Szó nincs erről.
Csak ha 3 diszkem van raid-ben, nem mind a 3-nak..
Mégiscsak kényelmesebb 1 jelszót beütni 3 helyett, nem ?
(Elég hosszú sajnos).
Ennyiről szól csak. Kényelmi nyafi volt, mindenképp vállalom a kézi jelszót természetesen, hogyne.
-
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.
-
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. -
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őrePer 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.
-
Dißnäëß
nagyúr
Értem. Köszönöm.
-
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"
-
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 ?
-
Dißnäëß
nagyúr
BIOS-ban is nézz körül, Guglit már széttúrtad gondolom, illetve egy BIOS frissítés.
Szóltam valamit, hátha.@ Kedves többiek !
Van 3db Debian rendszerem, mindegyik mai friss telepítés, iptables-ön kívül nincs még semmi különös állítva rajtuk. Mind tökfriss stable, stretch. Egyik az egyik laptopon VirtualBox-ban, másik a másik laptopon natívban, harmadik pedig egy magyar BIX-es VPS-ben.
Szeretnék kicsit tanulni. Nemrég fellőttem az egyikre (az az elődjére, mert újrahúztam végül) egy Citadel-t, adta nagyon. Eltelt a szombat.
A másikon meg elmerültem a kézi LUKS-ozás rejtelmeiben LVM-el kombinálva. Állat ez a linux nagyon.
Namost: van egy olyan elképzelésem, hogy mondjuk haverommal szeretnénk egy közös storage-ot elérni, ő otthonról az ő gépéről L2TP/IPSEC-et felépít W10 alól és lát mindent. Strongswan tudja, IKE1-el megoldjuk, összetákolom valahogy.
Szeretnék egy kis "HA"-t vinni a rendszerbe (erősen idézőjelben)
: bérelnék egy VPS-t külföldön is, a világ túlvégén, oda is felrántanék egy Debilt és szívesen összekötném a két VPS és a W10 gépek által egyaránt látott-megosztott mappákat.
Tehát: server1-en Mo-n lenne egy mappa, ezt (tehát cakkpakk az egész tartalmát) szeretném replikálni az itthoni 2 Debilre is, ami a háttérben kell, hogy menjen. Ahogy történik egy módosítás, az körbeszinkronizálódik az összes Debianon, a nagyon távolin is. És persze mindeközben helyben is tárolódik rajtuk ugyanaz a tartalom.
Például doksik, fontos anyagok, user könyvtárak, stb.
A be-VPN-ező W10-eknek egy SMB share kipublikálja a dolgot és ők is tapsolnak akkor.
Ezt szeretném ledemózni és kérdésem, hogy milyen instant szinkronizációs megoldást javasoltok ?
SZERINTEM amire szükségem van, az egy distributed file system és az most a legkésőbbi stable-ben a CEPH. Jó ez nekem ilyen célra, vagy ez kimondottan cluster cucc és illene a lassú, nagy latency-s kapcsolatok helyett egy Infiniband-en zavarni ? Esetleg egyéb háttérben-sync alternatíva ?Éles példa: 1 cég, 3 telephely és mindenkinek van egy kis saját mappája a fájljaival, meg közös mappák is, ezeket mindenki látja. Kézenfekvő lenne egy mindenki számára kényelmesen elért-kezelt distributed share-t használni, ami sync-elődget egymással, a 3 telephelyen lévő 3 linux gép között (és az egyes telephelyek W10 kliensei a helyi hálón nyúlnak ehhez a Samba share-hez).
-
Dißnäëß
nagyúr
Kedves haladók !
L2TP/IPSec: Openswan vagy Libreswan ? Tanácsot kérnék. A bérelt VPS-embe szeretnék "bejutni" két W10-es klienssel L2TP-n, Samba share eléréshez.
Libreswan: jó tutorial-t találtam hozzá, de nem fordul le egy idő után, hiányol valami .h fájlt a systemd-vel kapcs. Ezen lépkednék végig.. (új verziószámmal persze).
In file included from /root/ipsec/libreswan-3.23/programs/pluto/pluto_sd.c:22:0:
/root/ipsec/libreswan-3.23/programs/pluto/pluto_sd.h:22:31: fatal error: systemd/sd-daemon.h: No such file or directory
#include <systemd/sd-daemon.h>
^
compilation terminated.Openswan: elég új ? (Ez felment repo-ból, de nincs tutorial-om hozzá).
-
Dißnäëß
nagyúr
Flawless victory. Gondoltam, hogy ez lesz.
(És ezzel küldtek át a kezdőből a haladóba).
Bocs, hogy az időtöket raboltam. Szép estét. -
Dißnäëß
nagyúr
Sziasztok,
szeretnék egy titkosított fájlrendszert létrehozni, aminek tartalmát megosztomk Windows-os gépek számára.
1. létrehoztam egy 10 gigás fájlt.
2. luksFormat megvolt, kód, stb.
3. ext4 kreálva, rajta
4. mount-oltam
5. működik, teszi a dolgát szépen, /dev/mapper-ben is ott a viruális eszköz, szóval minden kerek.Viszont azt nem tartom normálisnak, hogy csak a root tud az újonnan mount-olt fájlrendszerre írni, vagy olvasni arról dolgokat. Sima user-nek is elérhetőnek kellene lennie.
Tehát root-ként mount-olom a /dev/mapper-ben lévő, immár "titkosítatlan" eszközön lévő ext4 fájlrendszert, de ezt szeretném bármilyen user számára engedni, kb. mintha egy új HDD-t adnék hozzá a rendszerhez és formázás után azt is eléri minden user, alapjáraton.
Na ezt csak a root és ezen szeretnék változtatni, mert ha Samba-val "kipublikálom" 2 Windows-os gépnek, amiket L2TP/IPSec-en belógatok a gépre a távolból, akkor gondolom ott normál user jogosultsági szinteken vagyunk.
Amit csináltam, root-ként:
mkdir /mnt/secret
fallocate -l 10G /mnt/disk.img
cryptsetup -y luksFormat /mnt/disk.img
cryptsetup luksOpen /mnt/disk.img secretdisk
mkfs.ext4 /dev/mapper/secretdisk
mount /dev/mapper/secretdisk /mnt/secretÉs ott a default lost+found könyvtár, minden szipiszupi, csak épp root szintet elhagyva nem férek hozzá a felmount-olt könyvtárhoz. Beenged, de már a lost+found-ba nem enged belépni. Írásvédett az egész cucc normál user-ként.
Valszeg banális dolog lesz. Tipp ?
-
Dißnäëß
nagyúr
Sziasztok,
Live CD vagy USB stick-re telepített rendszer esetén ha a HDD-t titkosítom, totál értelmezhetetlen random lesz a rajta lévő anyag, az első pár bájttal együtt, vagy van valami header-je az ilyen partíciónak ?
Ha nincs header, ergo megállapíthatatlan avatatlan szemnek, mi van rajta, klassz.
Ha van header, lehetséges boot és a partíció feloldása/mount-olása után a header-t felülírni, miközben élesben megy a rendszer és a HDD mount-olva ? Szóval ha jön egy áramszünet, egy header nélküli random bájtos titkosított hdd-m legyen, aminek titkosított partícióját újra boot-olva tudom használni ismét, ha feloldás/mount-olás előtt a header-t helyreállítom (majd újra törlöm).
-
Dißnäëß
nagyúr
Sziasztok, erre esetleg innen vki tudna adni par tippet ? Koszonom!!
-
Dißnäëß
nagyúr
válasz
Frawly #25821 üzenetére
Hmm korrekt válaszok, köszönöm.
Az SSD egy ilyen modell, legalábbis amin a rendszer(ek) van(nak). Ez támogatja az ATA jelszót, amiről írsz ? Adatlapja szerint van hardveres titkosítás benne, AES256, de hogy hogy kell ezt aktiválni egy akármilyen oprendszer telepítése előtt, nem tudom. (Nekem ez az infó új volt, hogy van beépített titkosításuk).
(A második SSD majd egy NVMe típusú lesz, a game-ek és a multimédiás motyók alá, de akkor abban is ilyet keresek majd).
nVidia-hoz kezdek a zárttal, hátha jó. Nyíltban azt írják nincs power saving motyó, az megeszi akkor igen hamar a kakaómat. (Bár AC-n mindegy, akkuról meg úgysem játszok).
-
Dißnäëß
nagyúr
Sziasztok Szakik !
Ekéztem az asztalit, lett egy laptop helyette. 3-4 hónap Win10-től kiakadtam, istennek nem tudom megszokni. Mivel régóta hobbi Linuxozom (Debian nagyon sokáig, mostanában Linux Mint, mert lustulok)
érdeklődnék, hogy szerintetek mi elégítené ki az igényeimet a legjobban:
- laptop, de ez egyik modern disztrónak sem okoz gondot kezelni sztem
- titkosítottra az összes háttértár (2db SSD), Linux alatt LUKS nem kérdés, /boot marad nyitott, többi titkosított. Elég csak egy lopás/elvesztés esetén elriasztani az embert a töréstől, nem pentagoni megoldásra gyúrok mint az Arch Linux, ahol a /boot is titkosítva..
- böngészés, net, üzleti dolgok (van egy vállalkozásom, abból élek, mobil vagyok eléggé, szóval levelezés, ilyesmik kellenek csak, LibreOffice, stb, ezeket backup-olnám rendszeresen felhőbe vagy még inkább valami otthoni motyóba VPN-en keresztül sync-elve beküldve).
- Starcraft II egy 2014-es cikk szerint megy Wine alatt, gondolom ma ez csak még jobb és tényleg megy szépen.
- Master of Orion (az új) SteamOS-nek hála natívban megy Linux-on, kipróbáltam, szuper.
- CS : Source: SteamOS-nek hála szintén natív, jól megy.
- Battlefield 4: na ez nagy fejvakarás, régi cikk szerint érkezik majd SteamOS-re, de azóta nem tudok semmit róla.
- Adobe Photoshop: megy Wine alatt rendesen ? A CC és nincs törve.
(Mellékes kérdés: kalibrálni lehet akár a beépített monitor, akár a külső monitoromat Linux Mint alatt?)Ennyi, ki is fújt. Hogyan oldanátok meg ? Saját elképzeléseim fentebb mögé írva halványan. (4 mag, 8 szál i7 Kaby Lake, nVidia GPU)
- bónusz kérdés: nVidia-hoz saját driver (nvidia-prime) ami elég zárt és kicsit szembehugyozzák egymást kölcsönösen nvidia és a linux közösség, vagy a reverse-engineered nouveau-prime ? Optimus-om van, igen.
Új hozzászólás Aktív témák
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Eladó Steam kulcsok kedvező áron!
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Bomba ár! HP ZBook Studio G5 - XEON I 32GB I 512SSD I Nvidia I 15,6" 4K DreamColor I Cam I W11 I Gar
- Beszámítás! Apple Mac mini 2023 M2 Pro 16GB 512GB SSD számítógép garanciával, hibátlan működéssel
- AKCIÓ! ASRock H310CM i3 9100F 8GB DDR4 240GB SSD 1TB HDD GTX 1060 3GB AeroCool Strike-X 500W
- Apple iPad Air 4 64GB Kártyafüggetlen 1Év Garanciával
- Bomba ár! Fujitsu LifeBook U757 - i3-7GEN I 16GB I 256SSD I 15,6" FHD I HDMI I Cam I W11 I Garancia!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest