-
Mobilarena
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
-
samujózsi
senior tag
válasz
bambano
#29399
üzenetére
????
Na ezt részletezd plíz, mert a "nemszabvány" csv ugye úgy néz ki, hogy egy sor = egy rekord, a mezők általában ;-vel (vagy más megadott karakterrel) szeparálva, plusz lehetőség van a mező tartalmának idézőjelezésére, hogy el legyen különítve a numerikus és a string adat (illetve ha a mező tartalmaz a szeparátorral azonos karaktert, akkor ott ne akarjon új mezőt a parser)
Ha valami egyedit csinálsz, annak már csak az általad adott neve csv. Szerintem. -
bambano
titán
válasz
samujózsi
#29395
üzenetére
"írj korrekt csv parsert shellben! (+1: minek, ha van készen más script nyelven?": azt felejtetted ki a történetből, hogy olyan csv parsert kell írnod, ami az általad generált, nem általános csv-t képes parsolni.
vagyis ha a parsered nem tudja parsolni a csv-det, akkor saját magadban kell keresned a hibát.
-
válasz
samujózsi
#29397
üzenetére
"While there are various specifications and implementations for the CSV format (for ex. [4], [5], [6] and [7]), there is no formal specification in existence, which allows for a wide variety of interpretations of CSV files. This section documents the format that seems to be followed by most implementations:"
Szoval nincs standard, csak szokasok. Ellentetben pl. az XML-el.
-
samujózsi
senior tag
válasz
bambano
#29394
üzenetére
Itt szokott előjönni (mármint a csv vs egyéb formátum témában), hogy
- azért mostanában elég ritka, ha egy fejlesztő csapat egy konkrét cég házi csapata, soha, senki másnak nem dolgoznak. Az jellemzőbb, hogy külsősök, saját kódbázissal x darab jelenlegi és y potenciális, jövőbeni ügyféllel. Emiatt akkor is muszáj univerzális megoldással jönniük, ha konkrétan nektek dolgoznak.
- írj korrekt csv parsert shellben! (+1: minek, ha van készen más script nyelven?) -
bambano
titán
válasz
haddent
#29392
üzenetére
itt megint a túltervezés példáját láthatjuk.
"ha kalapácsod van, mindent szögnek nézel"
biztos, hogy objektumként kell átadni a validált adatokat?másik hsz-edben:
"Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki, hogy univerzális és kompatibilis legyen ne csak a te shell scripteddel, hanem grayloggal, prometheussal, kibanával meg nagyjából bármivel is, ne kelljen külön parser meg interpreter hozzá. ": ezt max. akkor csináljuk így, ha feladat, hogy ilyen cuccokkal interfészelni kell. ha nem feladat, akkor nem csináljuk így."Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki,": vagyis csv-ben, és még véletlenül sem json-ben.
"Ebből a kommentedből is látszik, hogy nagyon más nézetet vallasz.": így van. ha például azzal kezdem a threadet, hogy "elsőnek bash", akkor ez alatt azt értem, hogy először bash és nem azt, hogy kizárólag bash.
-
samujózsi
senior tag
válasz
haddent
#29392
üzenetére
Ott a kulcsszó: szerializáció (fújj... nincs erre valami mádzsár ixpressön?
)
A csv az alkalmatlan erre, viszont egyszerű adatsorok továbbítására nagyszerű. Ha már van benne idézőjeles mező... hát akkor már mindegy.
Ezeket a dekorátorokat utálni fogom, amíg csak élek. Egyszerűen képtelen vagyok megjegyezni, hogy hol, hogyan tudnám használni saját célra.
-
haddent
addikt
válasz
haddent
#29390
üzenetére
Na meg van az a szint, amit bash -ben elkezdeni is nevetséges lenne, C/C++ -ban meg olyan szinten fájdalmas makrós szörnyedtség (vagy 3rd party keretrendszer és társai), hogy inkább feladod az életet is. Itt egy kis kedvenc pl. saját kód
Egy webszerver POST endpointját kidekorálom vele felparaméterezve egy előredefiniált schemával és hátradőlök, a függvény megkapja a parsolt, validált adatokat objektumként. Na ezt nagyon nem szeretném C -ben implementálni pl
samujózsi semmivel, ebben igazad/tok van. Nem tudom miért a json lett "A" (de)szerializációs best practice, de ez van. Mondjuk jóval jobban olvashatóbb és sokkal bonyolultabb objektumok kényelmes tárolására is alkalmas, gondolom..
-
haddent
addikt
válasz
bambano
#29388
üzenetére
Ebből a kommentedből is látszik, hogy nagyon más nézetet vallasz. Nem rossz vagy jó kérdése ez és nincs igazad meg nekem sem, továbbra is mindkettő kell. Egy modern, nagy, bővülő, naponta 10x commit-test-deploy ci óriás enterprise szörnyet a te módszereiddel borzalom lenne életbentartani, vagy inkább lehetetlen.
Pont a példád a tökéletes példa. Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki, hogy univerzális és kompatibilis legyen ne csak a te shell scripteddel, hanem grayloggal, prometheussal, kibanával meg nagyjából bármivel is, ne kelljen külön parser meg interpreter hozzá. A json beolvasása objektummá ami aztán iszonyú jól kezelhető pontosan 2 sor (melyből az egyik 1 import) Pythonban. Nincs elírás, nincs jajj idézőjel, space, nincs fájl ellenőrzés mert ez mind a beolvasó object exception modelljeinek része. Egyszerű, elegáns és nem utolsó sorban gyorsabb/hatékonyabb is mint a bash valószínűleg, mert egy agyonoptimalizált C kód-wrapper
A hálózati példád nem fejtetted ki ennyire, de vakon erről is kb. ez mondható el. Lehet iptables írogatni vimmel, csak aztán azt tartsa karban meg egyben aki nem normális.. Akár csak egy Vyos vagy pfSense sem tesz rá túl óriási absztrakciót, de épp akkorát, hogy át tudsz látni 1000 szabályt is.
Viszont van az a hely, pl. pont a kígyó saját farkába harap, Pythont nem lehet Pythonban fejleszteni, mert egy fos lesz. C -ben kell
Nem az absztrakció az ellenség.. nem hülyegyerekek találták ki ezeket és nem hülyegyerekek számára. Akkor van óriási probléma, amikor a hülyegyerek él az absztrakció nyújtotta lehetőségekkel és kényelmi funkciókkal úgy, hogy fingja nincs róla mi zajlik a háttérben. Na az k*#& gáz, és sajnos ebben viszont igazad van, hogy ez a többség. De nem a puska a hibás, ha lelőnek vele valakit..
-
samujózsi
senior tag
válasz
bambano
#29388
üzenetére
Én flame helyett maradnék a tények mezején.
Te gyűlölöd. Én tudomásul veszem, hogy ilyen és használom.
Ha valaki tanulni akar, annak szvsz nem azt kellene néznie, hogy egy szarrá hardeningelt/hackelt szerveren milyen lehetőségei vannak, hanem azt, hogy a tanulmányait befejezve, a témában kezdőként, milyen tudással tud elhelyezkedni, ha ez a célja.
Itt azért a bash elég sokadlagos szempontnak tűnik.
Linuxon ugyan default többnyire a bash, de rengeteg helyen futhat ksh-ba (*BSD), ash/dash/busybox shellbe stb.
Ezekből talán több van, mint kiherélt szerverekből. Unixból még nem láttam olyat, ahol ne lett volna perl felrakva, bár azt meg nem mondom, hogy mely unixon, melyik rendszerkomponensek íródtak perlben, valahogy a *bin könyvtárakban sohasem kerestem szkripteket, linuxon is tudom, hogy sok rendszeralkatrész (igaz, főleg GUI-s) íródott pythonban, de ezekre is igaz: tudom, hogy vannak, emiatt nagyon ritka, ha a python alap nincs fenn.Ui: vicces, a git ragaszkodik a perlhez?
ubuntu18.04 serveren ezt mondja -
bambano
titán
válasz
samujózsi
#29382
üzenetére
"Te egyszerűen gyülölöd valamiért.": igen, ez így van.
azért, mert azt látom, hogy egy csomó kód "overengineered", túl van tervezve, és ahelyett, hogy hatékonyan, tömören megcsinálták volna, "szépen" csinálták meg.egyszer régen egy korábbi munkámban monitoring adatokat kellett gyűjtenem egy appból, és a tisztelt fejlesztővel hetekig veszekedtem, hogy azt az adatot, amit egyszerű, egysoros, csv jellegű formátumban ki tud adni, ne json-ben meg xml-ben adja már ki, mert azt sokkal nagyobb meló parsolni.
de jártam már úgy is, még a múlt évezredben, hogy egy internet szolgáltató rendszerét megtervezték úgy, ahogy a cisco elképzelte (ami nyilván minél több dobozt akart eladni). lett belőle egy akkora architektúra, hogy a2-es lapra fért csak ki nyomtatva. azt megkaptam, kiröhögtem, utána megcsináltam ugyanazt shellben, összesen kevesebb, mint két képernyőnyi shell kóddal meg ötvenedannyi programmal.
ja nem. nem csak a múlt évezredben jártam így, hanem a mostaniban is...
de szerintem ha ebből flame-t akarunk csinálni, akkor élesszük fel egy korábbi posztom topicját és ott: [link]
-
haddent
addikt
válasz
bambano
#29381
üzenetére
Miért, Pythonban megfordult a menetirány meg az ifirány, vagy miről maradtam le? Vagy a generátorokra gondolsz, amikkel 1 sorban rendezel le egy 50 soros C headert?
Az indentálást syntax részévé tenni szerintem fura, de jó ötlet, szerinted szar. A végeredmény szerencsére az, hogy még a kókánygenyó indiánus "programozók" kódja is valamelyest olvasható, néha -
samujózsi
senior tag
-
bambano
titán
válasz
haddent
#29380
üzenetére
c-ben meg jávában (meg kb. mindenben) úgy írod, hogy:
if feltétel then feltételes ág;
ezt fordítva írni elég nagy bűntett. illetve tabulálást a szintaxis részévé tenni szintén az.
de nem is ez a fő probléma a pythonnal, hanem az, hogy arra csábít, hogy minden olyan dolgot, amit normális programozói felfogással bashban pár sorban el lehet intézni, azt pythonban írd meg, OBJEKTUMORIENTÁLTAN. ezért szívlapát járna mindenhol. folyton vitatkoznom kell olyanokkal, akik összekeverik azt, hogy valami szabvány lehet használni azzal, hogy kötelező használni.
tehát a vége az, hogy ha valaki betépve csinált magának egy programozási nyelvet, azt nem feltétlenül jó általánossá tenni. és igen, a rendesen telepített szervereken se python, se perl. minél kevesebb eszközt adsz a leendő betörő kezébe, annál biztonságosabb a történet.
-
haddent
addikt
válasz
inf3rno
#29373
üzenetére
Mondanám, hogy ízlések és pofonok meg szakirányok, de itt azért jóval többről van szó. Klisés kis példa, de jelen esetben egyébként tök jól szemlélteti a két nyelv és irány viszonyát: Pythonnal a NASA repül (és repült már régóta), Java -ból a (G)Ánydroid nem tud kigyógyulni 10 éve értelmes dologgá
Kicsit poénosra is fogtam, nehogy megsértődj, szíved joga Javat szeretni 
Láttam mindkettőt, egyetemen én szoptam C, ADA, ASM vonallal, másik szakirány röhögött jókat a Java -val. Én tökre értem mit szeretnek rajta sokan, csak azt nem, hogy a Pythonban hogy nem látják ugyanazt csak jobban és többet De hosszú téma, nem hittérítő szakkőr és úgysem változik semmi, peace tényleg bambano azért ez így erős. Még embeddedből se láttam régóta olyat, amin legalább egy Python2 és Perl ne lett volna. De természetesen egyetértünk, hogy bash -nak érdemes nekimenni ha Linux a fő irány, elsőnek. Az még erősebb, hogy bűncselekmények, ebben formában. Ha már úgy mondjuk, hogy az a bűncselekmény amit el lehet velük követni és a többség sokszor el is követ, akkor egyetértünk
Csak itt meg felmerül az, hogy C -ben még nagyobb ordas faxságokat lehet csinálni és csinálnak is. Nem egymás ellensége a kettő, sokkal inább kiegészítik egymást, szerintem (meg sokan mások szerint)I02S3F a bash-ben az lesz nehéz, hogy egy spaghetti bánat az egész. Mindenre van kb. 4 féle elfogadható és működő szintakszis, sokszor egyszerre botrányosan explicit, hogy már fáj leírni 200char hosszú sorban egy egyszerű dolgot, néha meg leírsz 4 betűt fura karakterekkel összekötve és feltepül 25 virtuális gép
-
samujózsi
senior tag
válasz
bambano
#29376
üzenetére
Hurrá... írtam féloldalnyi választ, majd a mobil "back" gombjával sikeresen eltüntettem.
Nem írom újra: az általános shell ismeret kötelező, a bash-t... nem vinném túlzásba. Napi munka során nem nagyon fut össze olyan rendszerrel az ember, ahol nincs perl és/vagy python, esetleg awk.
Olyannal inkább, ahol bash nincs. Pl. beágyazott rendszerek, routerek (busybox)
Persze ez csak azbén véleményem. -
bambano
titán
válasz
I02S3F
#29375
üzenetére
az egyetlen programozási nyelv, amiről nagyjából biztos lehetsz, hogy minden unixon és unix származékon van, az a shell. ha megtanulod a bash-t annyira, hogy azt is tudd, mi az, amiben elferdül az alap szabvány shelltől, akkor minden rendszeren fogsz tudni programozni vele.
ugyanez nem igaz se a pythonra, se a perlre, se a hasonló programnyelv-tervezési bűncselekményekre.
-
inf3rno
nagyúr
válasz
haddent
#29362
üzenetére
Nem tudom, én csak ránézek egy Python kódra és elfog a hányinger. Nekem a Java, ami mindig is tetszett, szép, rendezett. Kivéve a többszálú programozás, az annyira nem jön be egyik nyelven sem, abból nekem az tűnik vállalható iránynak, amit a nodejs csinál, hogy megosztott memória helyett mennek az üzenetek, de az meg gondolom jóval lassabb, mint a többi.
-
Dißnäëß
nagyúr
válasz
samujózsi
#29370
üzenetére
Az ntfs szvsz jó igásló, de annyira nem agyonszofisztikált, még az újabb iterációiban sem, mint a már említettek.
Van automatikus defrag W10-ben, igen, nálam ki is kapcsolva. Épp elég volt nagyjából 22 óráig másolni az adatokat egyikről a másikra, ami többnyire szekvenciális beolvasásra hasonlít (ha nem töredezett) és őrült random seek-elést hoz, ha töredezett. A forrás meghajtón, nyilván. Hát nálam középen volt kb. a dolog, de mindkét HDD tud olyan 150-160 mega körül, ehhez képest volt, amikor 30-50 körülre berogyott a motyó, mert seek-elt az a HDD, amiről épp olvasta az rsync a fájlt. Meg közben én tettem-vettem és csak azt hallom finoman, hogy a Seagate-emnek le akar esni a feje egy szimpla iso mellett is (tartok 1-2 Linux telepítőt is magamnál itthon). Hát mondom uhhh, ideje volt. Ugyanez az újról visszaolvasva /dev/null-ba nyersen gyakorlatilag full tempón megtörténik, seek hang nulla (bár a Purple amúgyis halkabb, de kihallom ha akarom, hát semmi nem volt).
Már 1 tera is nagyon sok. Nagyon
Az ember akkor jön erre rá, mikor egész élete belefér párszáz gigába, sőt, .. és mikor másolsz, másolsz és másolsz és csak vánszorog tetű lassan, uhh .. 4 tera = ~8 óra, szekvenciálisan, lehetőleg nulla nagyobb seek mellett, így tartható a névleges (átlag-)tempó (150MB/s). Ha a matekom nem csal. Egy töredezett HDD-ről, fájlokat másolva, nagyon megcsúszik. (Blokk módban dd-vel átment volna említett idő alatt max tempó mellett, csak akkor ugye a teljes cluster map-et, minden vittem volna, a töredezettséggel együtt). És még mindig jobban jártam így, mintha engedtem volna a Windows-nak, hogy le-defragolja telibe, pici apró blokkonként téve az adatot egyik helyről a másikra, iszonyú sokat bukva seek időn. Sehogy se jó, de a kevésbé rosszat sikerült meglépni.
-
Dißnäëß
nagyúr
válasz
samujózsi
#29368
üzenetére
Én ntfs-t, egy hete. Vettem a meglévő 4 terásom mellé egy másikat, hogy na majd jól megnasozom itt a kicsi itthoni életem.
És akkor szembesültem több évnyi fragmentációval az ntfs-en, uh mondom neeee. Végül az lett, hogy btrfs-t kapott az új, áttoltam oda mindent egy rsync-el és most mindkét helyen megvannak az adatok. Az új diszk jó, agyon teszteltem, így bevállalom most azt, hogy egy zfs-t kreálok a régin, lezúzva mindent rajta nyilván, majd arra átteszek mindent az újról, végül az újat is leradírozom, zfs, majd a két zfs-t mirror-ba vágom és elvileg műxik úgy a dolog, hogy adat megmarad.
Mindezt még egy VM-ben kicsiben ledemózom és akkor elvileg jó leszek + fragmentációm sem lesz a fájl szintű másolás miatt. Legalábbis mondjuk úgy, tutira nem.
Megspórolhattam volna egy lépést, ha eleve zfs-t teszek az újra, csak meg akartam még őrizni a btrfs kompatibilitást pár napra, elég aktív zenehallgató vagyok és a W10-em látja a btrfs-t, illetve asszony raplizott, hogy elkésünk vendégségből, NAGYON csúnyán nézett, így nem volt kedvem agyonparaméterezett, jól optimalizált zfs-t kreálni rajta, maradt egy quick&dirty btrfs.
Mára meg letisztultak a dolgok, szóval...
Persze a legfontosabbakról van mentés, külső USB ház ...
Sokmindent mondanak amúgy defrag-ról, de én mostanában rájöttem arra, hogy jobb referenciadoksik alapján menni és ők általában szépen kitérnek arra, mikor igen és mikor nem. Ha jól csináljuk, soha nem kell, én sem tervezem.
-
samujózsi
senior tag
válasz
Dißnäëß
#29366
üzenetére
Nem akartam beleszólni, mert rákeresve az ext4 defrag kifejezésre jött használhatónak látszó találat, inkább hallgattam. De én is úgy tudom, hogy már ext2 óta nincs igazán szükség defragra, mi több, én úgy hallottam, nem is javasolt.
Valaki említette az ntfs-t... én utoljára fat32-t kényszerültem defragmentálni. (Win98) -
Dißnäëß
nagyúr
Így van. Általában. (Köszi a pontosítást).
Érdekes amúgy, mert az ext4 még csak nem is CoW fájlrendszer, míg egy btrfs, zfs igen. És még ezeket sem feltétlen kell defrag-olgatni, pedig jobban van bennük az implementálva, hogy ne fragmentálódjanak annyira és ez működni is látszik, míg nincsenek agyon-teleírva (kb. háromnegyede egészséges maximum). -
Dißnäëß
nagyúr
válasz
haddent
#29362
üzenetére
Szvsz úgy érdemes DevOps-ot tolni, hogy miközben egy programozási nyelvet tanul az ember, elkezdi alulról a classic IT stack-et is tanulni, az pedig infrastruktúránál kezdődik.
Nem kell CISCO CCNA (de nem ártana)
... de az OSI modellt betéve illik tudni, vagy hogy mi a különbség egy Layer3/4-es illetve Layer7-es load balancer között, amikor 2+ fizikai host-on, egyszerre több VM-ben a legkülönfélébb dolgok futnak HA-ban, mert az az igény ? És akkor jön az Apache, Tomcat, HAProxy, nginx, meg egyéb reverse és normál proxy típusok, egy kis HyperV-zés, fájlrendszer típusok és alap hatásuk (előny, hátrány), némi VMWare-ezés, például affinity group-ok, vCPU-k, aztán storage kapcsán NAS, SAN, vSAN, Fibre Channel, vissza network környékére biztonság, csomagszűrő és application tűzfalak, nat-olgatás, VLAN-ok, QoS, majd egy kis security alapok, PKI, RSA, ilyesmik.. úhhh nagyon hosszú még a lista és egy kurva kódot nem ütött le az ember, nemhogy OS-t telepített volna. Sokkal inkább mennék DevOps tudás felszívása esetén időrendben inkább, tehát infra, network (néha egybeveszik), DB, OS, APP, middleware, virtualizáció, konténerizáció, aztán jönnek a logikai szerkezetek, mit hol min tároljunk, fájlrendszerek és azok előnye-hátránya, local/distributed, és melyiket mikor mire, minimális SQL és azokra az elérés, konnektorok (ha kell), [... nagylevegő ...]
és még felhőnél sem járunk, microservices & GW-s, messaging queues, .. szóval az egyik agyféltekét full erre a classic stack-re fókuszálnám, ami mára már rendesen bebonyolódott-fejlődött, de azért az alap legó kockákat ismerni illik. Másik agyfélteke meg mehet python-ra közben, bár ez is érdekes, mert én node.js-en kezdtem és hogy is mondjam.. fasza.
És akkor lehet SOAP-ozni, XML, mert multik azért nem feltétlen tartják az iramot mindig a legújabb motyókkal, majd JSON/REST, API dolgok.. Van egy frontent fejlesztő haverom, fiatal srác, marha komoly guruja több nyelvnek is, kicsit most van fullstack-esedőben, de ahogy megy lefele backend irányba (még nincs a közelében), már bejön az, hogy fogalma sincs, mi az a MySQL Router, mire jó a Ceph, zfs, brtfs, XFS (és mire nem), raid szintek, raid kontrollerek (vagy nemkontrollerek), na meg akkor ismét csak network stack és suricata/zorp/ufw/iptables/routing/portok/socket-ek/vpn módszerek és típusok (pl. OpenVPN-nél nagyon nem mindegy, hogy tap vagy tun), ..
Nem rossz ez a modell szerintem és a 4-es pont nagyon is valid, sőt. Mai világban, ahol minden mindennel össze van kötve, abszolút must-have, sokkal több, mint esti mese, amit lehet csak úgy skip-elni és majd összeszedni wiki-ről, amikor odaér az ember. Pont fordítva gondolom: ha fejlesztés közben kell megoldás valamire, annak utánajárni sokkal kisebb rizikó - remélhetőleg nem refaktor indukáló
- mint egy felépített várnál mikor kiderül, hogy a ZFS alatt a raid kontroller nem IT módban van, vagy storage-ban mekkora legyen egy blokkméret, milyen redundanciát adjunk, vagy hogy mekkora VM kell egy új akárminek, esetleg konténerizálható-e de akkor swap-et ki kéne kapcsolni, ilyesmik + a teljes megoldás monitorozása, nem feltétlen nagios (bár aki szereti).. de akár ELK, akár más.. kinek mi a szájíze .. (vagy egy felhős dashboard és annak elemei), .. A DevOps szvsz úgy mindenes, hogy ő nem a "mindenes informatikus" aki elvan a sarokban facsén és közben a főnök tudta nélkül csorog le a poresz az üvegen, mert megteheti, hanem az, aki end-to-end képes átlátni egy üzleti igény megvalósításának kihívásait mind programozástechnikai, mind alátett infra szempontból és akkor SOKKAL de sokkal nagyobb esélye van arra a cégnek, hogy egy új gigaprojektet nem kell 2 év múlva kikukázni, mert kiderül, hogy vagy nem skálázódik, vagy szarul, vagy megesz valami erőforrást, holott nem feltétlen kéne, vagy inkonzisztensen tárolódik valami adat, queue, akármi.
Nagy felelősség van egy jó DevOps-oson, ha nekem cégem lenne és menne jól, mocskosul megfizetném, hogy nálam maradjon (ha jó).
-
Jester01
veterán
válasz
Dißnäëß
#29356
üzenetére
Az is régi bölcsesség, hogy az ext fájlrendszerek nem annyira hajlamosak a fragmentálásra, hogy ezzel foglalkozni kelljen. Pl.
usr: 248667/1310720 files (0.2% non-contiguous), 3049959/5242880 blocks
data: 1747239/7813120 files (3.3% non-contiguous), 105450969/124999728 blocks -
haddent
addikt
válasz
I02S3F
#29359
üzenetére
Először is, igaza van a többieknek. DevOps és Linux (sysadmin?) két tök más témakör. Persze van kapcsolat, sok szoros is, de ennyi erővel a programozóval is meg még ezer másikkal (egyébként a DevOps kicsit mindenes IS, dolgoztam 1.5 évig DevOps -ként).
Az 1. pont mindenképp kelleni fog mindkettőhöz, én mindenképp a Pythont ajánlanám, mert egyre csak nő a részesedése, tavaly már #1 volt. Modern, hatékony (C libek), nagyon szép explicit syntax, rengeteg nyálcsorgatós syntax sugar, programozók nedves álma, első nyelvnek is, és a DevOps is szeretettel használja glue languagenek, scriptelni, összekötni. (későbbiekben ha komolyabban érdekel viszont kötelező szopni C -vel is kicsit!) Linux specifikus esetén bash kötelező
A 2. pont számomra majdnem teljesen irrelevánsnak tűnik. Egy része nagyon mély és régi dolgok amikkel napi szinten nem foglalkozik egyik sem (threads, concurrency stb.. tanultam egyetem, de őszintén felesleges első körben, nem kernel fejlesztő leszel..), egy része meg nagyon modern és advanced (virtualization)
A 3. pont eddig a legfontosabb, nem is értem miért nem 1. számú.. Mindkét OS esetén, bash/powershell és terminál minden mennyiségben. Addig kár is kicsit is komolyabban belevágni, amíg nem tudsz minden problémát terminálból megoldani, +pont jár érte, ha már undorodsz a gui -tól és direkt terminálból esik jól minden
4. pont fontos és hasznos, deeee azért ez ilyen estimese, elolvasod, megérted aztán amikor épp valamelyik nagyon mélyen kell majd belemélyedsz
5. esszenciális, mindegyik! Sysadminnak és DevOpsnak is. nginx/apache lefedi a 95% -ot, maradék 4% IIS (win), a maradék a többi viccelődjünk kategória. Nginx -et ajánlanám, az mindent is tud, jól, nem véletlen #1 minden értelmes helyen
6. Container, orchastration, infrastructure provision én inkább ezzel összecsapnám a 2. pontból a vm -et. Kell, és nagyjából itt ~6. pont idejében releváns is már. Linux esetén egyértelműen KVM és Docker, Kubernetes. Minden más megint csak ilyen szenvedjünk egy sort kategória, meg ha épp adott melóhelyen mégis valami elavult szar van, akkor 10 perc alatt beletanulsz, ha ezeket mélységeiben ismered, érted, használod
7. Nagyon fontos, nem nehéz. Jenkinst ajánlanám, teljesen free/open source, millió plugin. Pl. jó ötlet (meg innentől mindenre) feldobni 1 már megtanult konténerbe és játszani vele
8. Nagyon fontos, el lehet benne veszni, de azért mire ideérsz belejössz. ELK, Graylog, Grafana, Prometheus, CheckMK, QRadar. Szerintem ezek a relevánsak manapság, itt is elég elavult a lista.. nagios az alapja soknak, de magában már nem sok szart ér
9. Hát ja ez már a csúcs, mindent valami távoli cloudban deployolvaBocs a hosszú válaszért, de ha komolyabban érdekel a dolog szerintem érdemes ezt az álláspontot is meghallgatnod, ez viszonylag friss tapasztalaton alapul, utóbbi 5 évben 1.5 év multinál devops, 1 év full stack developer, 1 év sysadmin / network / sec analyst. Természetesen nem kell egyetérteni meg szentírásnak venni, ahogy mondtam tapasztalat és vélemény
-
I02S3F
addikt
Sziasztok!
Főleg a Linux-al dolgozók véleménye érdekel!
Tudást szeretnék gyűjteni elsősorban, Linux témában. Erre ez a devops roadmap jó szerintetek?
A gyakorlati része odáig terjedne, ameddig otthon meg tudom oldani saját eszközökkel. -
Dißnäëß
nagyúr
válasz
Frawly
#29357
üzenetére
A stream nálunk is megy, torrenten viszont már nem vagyok, valahogy elmúlt az a korszak. Mármint regisztrálós oldalra gondolok.
Régi dal az oda-vissza másolás, bár én még sosem éltem vele, mindig programmal defrag-oltam. Most viszont nagyon jól jön, hogy csak szekvenciálisan kvázi nagyobb fejleszakító seek nélkül ír ki a cél HDD mindent. Gyorsabb is, mert a rengeteg seek idő rengeteg apró olyan idő, amikor épp semmi nem történik, csak várunk, hogy a fej A-ból B-be érjen.
Szóval összességében egy 4 terás, majdnem csurig HDD-t klasszisokkal egyszerűbb úgy defragmentálni, hogy átmásolom egy másik 4 terásra, majd vagy otthagyom, vagy vissza.
Persze ez fájl szinten él, ha nekem spéci dolgaim vannak, spéci rejtett blokkok, amikre szüksége van bárminek is, blokk szintű átvitel kell (pl. dd). De nekem csak fájlokat kell most mozgatnom hálistennek.
Az más, hogy csak ilyenre luxus tartani +1 üres másik 4 terásat. Szóval csak úgy mindennap egy ilyen nem kivitelezhető kényelmesen.
-
Frawly
veterán
válasz
Dißnäëß
#29355
üzenetére
Nem jöttem le a szerről. Azóta elérhetővé vált egy csomó streamszolgáltatás, Netflix, Spotify, játékoknál Steam és GOG akciói, így nagyrészt már nem nagyon szorulok rá torrentezésre. Meg a torrentoldalon is előfizettem prémiumra, szintén akcióban, így már seedállományt sem kell tartanom. Így meg kb. a béka segge alá zuhant vissza a torrentezési mennyiség.
A fájlrendszerek közül sokat közvetlenül is lehet már töredezettségmentesíteni, ext-akárhány, btrfs. Biztosan van még egy csomó. Ez ilyen régi dal, hogy oda-vissza másolással kell töredezettségmentesíteni, még abból az időből maradt vissza, mikor még szinte egyik linuxos fájlrendszeren sem volt defrag tool.
-
-
Dißnäëß
nagyúr
válasz
Frawly
#29354
üzenetére
Kezdesz Te is már vénülni, jössz le a szerről, a sok torrentről meg marhaságról ..
Az urandom amúgy úgy van, ahogy mondod. Gyorsabb, mint a sima random, de annyira nem, hogy nálam a HDD-t kimaxolja, mondom, ilyen 60 Mb/s körülre állt be urandom-os DD-zés egy Ryzen 5 3600-ason (1 szálat 100%-ra pörgetve). Az nem valami rakéta
főleg ekkora HDD-knél. Sebességben pedig kicsivel a gyakorlati 150Mb/s szekvenciális harmada körül-felett és 1M blokkmérettel dolgoztam már, kevesebb overhead-hez. (bs=1M)Más:
rsync-elek éppen "A" HDD-ről "B"-re, úgy hagytam a gépet reggel. Egy cp-s paranccsal szemben ennek a fájlmásolásnak csak a metódusa más (nyilván sokkal több extrát is tud az rsync), de megőrzöm azt az előnyt rsync-el is, mint cp-nél, hogy a fragmentációt nem hozom át, igaz ?A régi 4 terásom 3.7-ig be van telve, őrült sok adat és marha fragmentált már, nálam Windows automatikus defrag ki van kapcsolva tudatosan. Nem mintha a bekapcsolt sokat segítene, sőt, inkább rizikózok, hogy kinyírja a HDD-t idő előtt.
Most, hogy NAS-ba teszem, célom átmásolni mindent az újra, amire gyorsan kreáltam egy btrfs-t és most is épp csorognak át az adatok. Amit hallok az az, hogy az újnak nincs hangja, a régi pedig néha seek-elget, néha darálgat kicsit egyet, mikor hogy ugye.
Feltételezem, a régi fájlrendszer töredezettségét az átmásolással az újban megúszom, így van ?
(Ha blokkonként, dd-vel másoltam volna a régit az újra, akkor vitte volna magával a töredezettséget is - annak nem láttam értelmét).
-
Frawly
veterán
válasz
samujózsi
#29349
üzenetére
Lehet az a baj, hogy még régen próbáltam, régi gépen, 2 magos Core Celeroncs proci. Igen, gyorsabb volt a /dev/urand, de még azt is kínzás lett volna kivárni egy ~200 gigás meghajtónál is. Lehet mai normális gépen próbálnám, nem lenne már olyan nagy szám. Lehet egyszer ki is próbálom, akár még dd if=/dev/urand of=/dev/null segítségével is, jó sokáig, hogy mennyit tol át. Hétvégénél előbb nem lesz időm most ilyennel játszani.
Nekem egyébként bőven elég az egy menetes zerofill. Vagy SSD-nél az egy menetes TRIM (egész meghajtóterületen, nem csak a szabad szektorokban).
(#29350) haddent: nálam semmi különös. Régen főleg nagyobb léptékű torrentezés miatt titkosítottam. Ma már sokkal kevesebbet torrentezek, alig valamit, inkább csak személyes doksik vannak a gépen, semmi komoly hadititok. Inkább csak megszokásként maradt rajtam, hogy ha egyszer elérhető titkosítás, meg nem lassít, akkor miért ne használjam. Bár nem mindent titkosítok, próbatelepítéseket pl. nem, mert azokon OS-eket tesztelek, vagy csak 1-2 játék miatt vannak fent, azokon semmi személyeset nem tárolok amúgy sem, meg egy idő után mindig törölve is vannak ezek. Igaz én semmi ultraparanoid szigorítást sem használok hozzá, default beállításokkal titkosítok mindent. Tehát semmi ilyen header nélküliség, meg random felülíráshoz ragaszkodás, stb.. Annyira érdekes dolgaim egyébként sincsenek, hogy valakinek túl sok energiát érdemes lenne beleölni a visszafejtésbe.
Azért valami titkosítást nem árt használni. Engem azért nyugtalanítana, hogy ha valaki idegen ráteszi a kezét a gépre, nézegetheti, hogy mi van a browser historyban (nem, nem fogom törölni minden kilépéskor, kényelmetlen, a weblapokra visszataláláskor hasznos), mit töltöttem le, milyen doksikat írtam, kivel leveleztem. mondom semmi nagy titokról nincs szó, de ne legyen már az életem bárkinek nyitott könyv.
-
haddent
addikt
Amúgy ti miket tároltok így a h/sdd -iteken?
Én pont leszarom, ha 1:1 -ben viszik az itthonit meg a cégest is, pedig "C" típusú bevizsgálásom van, tehát a munka kényes eléggé, csak nem tárolok rajta semmit Amúgy is a legjobb hely a google drive! Ingyenes, sose vész el, ha kitörlöd is vissza tudod kérni 40 év múlva is a nagytesótól -
samujózsi
senior tag
válasz
Frawly
#29347
üzenetére
A /dev/random szokott döglassú lenni, különösen, ha nem áll rendelkezésére... entropy magyar megfelelőjét nem tudom, de az szokott nullázódni/kiürülni.
Ez elvileg valódi véletlenszámot generál.
Az urandom alapvetően gyorsabb, de pszeudovéletlen, titkosítással kapcsolatos műveletekhez nem javasolt a használata. -
Frawly
veterán
válasz
Dißnäëß
#29345
üzenetére
Ebben lehet igazad van. A /dev/random-ot és a /dev/urand-ot egy régi gépen próbáltam anno, azon olyan baromi lassú volt, hogy önkínzás lett volna végigvárni. Lehet sok magos modern gépen már gyorsabb, és kimaxolható vele az I/O sávszél.
LUKS-nál nem kell semmilyen header-t dd-zni, crypsetupban megadható, hogy hová tegye a header-t, ne a disk-re tegye.
Viszont a LUKS format valóban gyorsabb a /dev/urandnál, ha a gép támogatja a hardveres AES gyorsítást, értve ez alatt, hogy a prociban van ilyen extension támogatva.
-
Frawly
veterán
válasz
samujózsi
#29344
üzenetére
Tévedsz. Headerrel sem törtek fel még soha LUKS titkosítást. Lehet akármilyen lelkes akárki. Már a 128 bites AES-t ilyen 8 karakteres jelszóval is csak szuperszámítógéppel tudnak törni és évekig tart, 256 bites AES-t ilyen 20-30 karakteres jelszóval és XTS blokktárolással (ezek a default értékek LUKS-ban) meg kb. soha, esetleg az univerzum végégig tartana. Hacsak nem találnak idővel valami gyengeséget magában az AES algoritmusában, vagy a LUKS blokkezelésében (a CBC-ben találtak, igaz abban is csak elméletileg, azt nem is használja már default semmi).
De nem kell ehhez LUKS sem. Az eredeti UNIX forráskódjában ott maradt néhány UNIX-os fejlesztő felhasználói fiókjához tartozó jelszó hash-e. A legtöbbet megtörték néhány perc-nap alatt, de azok egyszerű jelszavak voltak, 4-5 karakter, és egyéb blődségek. Viszont volt ott pár emberke, akinek a jelszavát már több mint 10 éve nem tudják visszafejteni, pedig számos hobbista dolgozik rajta, ilyen erősen párhuzamosított, csúcs GPU-s / bitcoinbányászatban edzett vasszörnnyel mennek rá, és még mindig semmi eredmény. Pedig ez nem AES, meg SHA512 meg LUKS XTS, csak egy mezei, régi hash, egy 70-es évekbeli rendszerről visszamaradva. Nem is komoly szándékkal törik, csak egyfajta fun hobby projekt, hogy a régi nagy UNIX-szerzők közül ki milyen jelszót használt.
A Secure erase-nek ha van is hiányossága, nehéz kihasználni, mivel az SSD vezérlőjét kell hozzá megkerülni, az meg eleve rettenet nehéz, csak ilyen NSA, CIA szintjén ha lehetséges, és még ott sem garantált a siker, hogy a tényleges töréshez találnak is rajta fogást.
Szóval maradjunk abban, hogy ha el is adok a jövőben háttértárat, az új tulaj lehet bőven lelkes, de hozzáférni maximum a p5sömhöz tud, ha lent van a sliccem, akkor is csak úgy, hogy ha engedem, hogy l3×0pjon kézen állva.
-
Dißnäëß
nagyúr
válasz
Frawly
#29343
üzenetére
- /dev/zero sebessége a diszk maximuma, esetemben fejpozíciótól függően átlagosan 150Mb/sec.
- /dev/urandom CPU mag 1 szál sebesség függő, nálam úgy 59Mb/sec
- szintén diszk maximumot tudsz randommal teleírva elérni HD Sentinel-el... (Windows alól)...
- és Linux alól úgy, hogy egy cryptsetup luksFormat-al leformázod, titkosított kötetté kvázi, ami tökrandom mintával tölti fel az egész lemezt, a végén pedig le-dd-zed a headert, vagy ha biztosra akarsz menni, 1mp alatt bele-urandomolsz dd-vel az elejébe, pár megába, és jónapot, eladható, randomizáltan, linux alól, diszk max sebességen végrehajtva.
-
samujózsi
senior tag
válasz
Frawly
#29343
üzenetére
Ha ott a header és teszem azt az a jelszó, hogy abcd, azt viszonylag könnyű kitalálni, ha kellőképp lelkes az "új tulaj", még hozzá is férhet a lopott diszk adataihoz.
Header nélkül cseszheti, mert nincs meg a kódoláshoz használt kulcs, ami nagyon nem azonos a jelszóval.
Ezt nem vagy képres megérteni.
Secure erase-t meg úgy tudom, egyébként sem támogat minden+ vannak hiányosságai stb. -
Frawly
veterán
válasz
samujózsi
#29331
üzenetére
Akkor is lehetetlen feltörni, ha ott a header. Ezt képtelen vagytok megérteni, nem tudom miért.
Én nem szoktam eladni háttértárat, használom, amíg tönkre nem megy. Ha SSD-t adnék el, akkor vagy security erase-t nyomnék neki hdparm-mal, vagy ha ezt nem tudja, akkor blkdiscard paranccsal végigtrimezném (ez sajnos az overprovisioning területet nem törli, de a gyakorlatban egész jó hatásfokú mégis). Ha HDD-t adnék el, akkor egyszerű dd if=/dev/zero segítségével mennék rajta végig, egyetlen menetben, senki nem talált fogást még ezen a módszeren a gyakorlatban, és sokkal gyorsabb, mint a random adattal teleírás. Ami a legfontosabb: ezt közvetlenül az eladás előtt tenném meg, nem napokkal, hetekkel előre. De itt most nem ez a lényeg. Hanem hogy nem hiszem el, ha egy gépben random teleírt meghajtót látok, hogy eladás a cél. Lehet hogy ti ilyen naivak vagytok, én azonnal tudom, hogy semmilyen eladásra szánás nincs itt, a gép tulajának rejtegetni valója van és titkosít. Ennyi. Nem kell ebbe mindent belegondolni, nem a technikai szintről van itt szó, hanem életszerűségi, élettapasztalati logikáról.
Kb. olyan, mint mikor mindenki veri a mellék, hogy ő csak azért használ torrentet, mert csupa legális anyagot tölt, pl. Linux .iso-k. És bár lehet valóban erre használni, azonnal tudjuk róla, hogy bullshit, mert kifejezetten azért találták ki a torrentet, hogy jogvédett meg fizetős anyagokat tudjanak vele letölteni, és akinek fent van torrentkliens, az 99,9999999999999999999999%-ban nem csak Linux iso-kat tölt. Amivel nincs is semmi baj, csak akkor a bullshit szövegeket nem kell tolni hozzá, pl. én is torrentezek, film, sorozat, néha zene, régi játékok, stb.. Épp így a titkosításban sincs semmi kivetni való, én is használok, csak nem nyomom mellé a kamu dumát, hogy bla-bla, nem tehetek róla, áldozat vagyok, NSA elől bujkálok, eladásra lesz, meg egyéb sóder.
Na, ugyan ez van, hogy ha egy gépben teljesen random teleírt meghajtó van, én tőlem mondogathatja a tulaj, hogy eladás, meg möhöhőő, nem fogok neki hinni. Mert nem vagyok naiv, és tökéletesen tudom, hogy nem vagyok ezzel egyedül, mert itt a szakmailag kompetens kollégák is így gondolják, ismerem őket annyira, hogy ők sem ma jöttek le a falvédőről. De ha akarjátok, nyugodtan ragozzuk még, nyomhatjátok mantrában, hogy biztosaneladás, biztosaneladás, biztosaneladás, meg nincsheader, nincsheader, nincsheadeer, elméletileg, elméletileg, elméletileg, hátha segít az önámításban.
-
-
-
Dißnäëß
nagyúr
-
samujózsi
senior tag
válasz
Dißnäëß
#29335
üzenetére
Nem akarok nagyon kötekedni, de ez tényleg túlzott para.
A biztonság, az biztonság, függetlenül attól, hogy privát vagy enterspájz.
Ez a terelés csak hamis biztonságérzetet kelt.
Kb olyan, mint routereken a MAC szűrés.
Ettől nem lesz biztonságosabb.
Ha félted az adataidat, legyen egyetlen, kellő bonyolultságú és hosszúságu jelszavad, a többi slot maradjon üresen és nincs vele gond.
Nézz körül a cvedetails oldalán( [link] ), hogy milyen ismert problémák voltak, esetleg vannak a diszk titkosítással!
Átfutva rajta, maga a LUKS biztonságosnak tűnik, de nem néztem végig egyesével. -
Dißnäëß
nagyúr
válasz
Frawly
#29328
üzenetére
Jelszó az USB stick-nek, mivel az is titkosított, GRUB Luks1-es formátumig jó. Ennek kézi jelszavas feloldását követően válik elérhetővé az a kulcs, vagy azok a kulcsok, amik feloldják a többi, Luks2-es HDD-t. Semmi extra. A többit pedig elküldöm kellően okos módon a protonmail-emre, egy veracrypt konténer fájlba téve, zip-elve, meg elrejtem még itt-ott a nagy világhálón, ha az életem akarna múlni rajta.
Így mindkettő teljesül, kellően random és nagy kulcs is a tényleges drive-ok feloldásához, meg a kényelem is és az 1 darab jó erős jelszó, ami lehet Biblia idézet, Wales-i bárdok, vagy női nemi szerv, bármi, amit akarunk
Nyilván semmi ilyen durva cucca nincs senkinek kb, csak elméletben beszélgetni érdekes ezekről.. ennyi "szenvedést" az egész nem ér egyébként, valóban.
-
Dißnäëß
nagyúr
válasz
samujózsi
#29331
üzenetére
Amúgy ez érdekes, én eleinte DD-vel gyalultam őket nullásra szintén, legutóbbi 3 Seagate vinyómat pedig eladás előtt HD Sentinel Surface test WRITE módban, random pattern-re állítva. Épp zenét hallgattam Foobar-omon és lusta voltam kikapcsolni és Linuxba át-boot-olni
Ez ekvivalens nagyjából egy dd if=/dev/urandom of=/dev/sdb bs=1M cuccal
-
Dißnäëß
nagyúr
válasz
inf3rno
#29327
üzenetére
Enterprise környezetben a titkosítás indokolt és nem szükséges vagy nem érdemes titkolni, hogy egy elhagyott laptop SSD-jén vagy HDD-jén titkosított az adat (Bitlocker jellemzően, de bármi egyéb akár). Tudjuk, hogy így mennek ezek a dolgok.
Ellenben magánemberként ugyanez már egészen más tészta, a biztonságnak a gyanúelterelés a legelső frontvonala (hogy meg se próbáljon nekiesni bármivel is, az agyában se forduljon meg még csak ötlet szinten sem).
Kb ennyi és ebben nincs semmi túlpara
-
samujózsi
senior tag
válasz
vargalex
#29332
üzenetére
Márhogy mi? Átírod a diszket? Mert az teljesen egyértelmű egyébként.
Elképzelni sem tudom, hogy a tudatlanságon túl miért ne írná felül valaki a diszket, ha tovább adja... akár eladásról van szó, akár csak céges gazdacseréről. (notebook/PC stb)Egyébként SSD-knél állítólag érdemes vigyázni, mert a firmware tömörít, meg deduplikál esetenként, emiatt a /dev/zero-val felülírva nem ír át semmit, ráadásul egyszeri teleírás miatt pár blokk (viszonylag sok) sértetlen is maradhat a dedup/tömörítés miatt.
Erre egyik megoldásnak javasolták a többszöri felülírást, másiknak a hardveres jelszó beállítását, majd törlését, mert ezzel új kulcsot generálnak az SSD-k az alapvetően titkosítottan tárolt adatokhoz, amihez így többé semmilyen módon nem lehet hozzáférni.A fentiekkel annyi a gond, hogy emlékszem rá, de a forrásaimról, illetve azok megbízhatóságáról semmi infóm. És hát... szóval én picit hitetlen vagyok, hogy ez mind igaz.
(ugye SSD-nél vannak "varázslatok", amivel szakember sokmindent vissza tud nyerni még egy törölt SSD-ről is adott esetben) -
samujózsi
senior tag
válasz
Frawly
#29330
üzenetére
Bocs, de ez már a ROTFL kategória.
B+, te nem gyalulod le a diszket, mielőtt akár géppel együtt, akár gép nélkül eladod???
Ahány diszket eddig eladtam, azt mindet vagy a /dev/zero vagy újabban a /dev/urand-ból vett "adattal" felülírtam, pont úgy, ahogy írod, a 0.-tól az utolsó bájtig.
Szerinted mégis mit kéne vele csinálni, hogy valami recovery szoftverrel ne tudja a kedves vásárló visszaszedni a diszkemen tárolt adatokat?A srác kérdésének megfelelő kialakítás az pont olyan (feltéve, hogy a LUKS/md-crypt nem hagy spéci ujjlenyomatot - ezt nem tartom lehetetlennek), mintha random adatokkal teleírtad volna a diszked, mivel header nincs rajta.
Az úgy tényleg csak random adat egyébként, pont azért, amit korábban már említettem: a kódoláshoz/dekódoláshoz szükséges kulcs header híján nincs a lemezen, azt meg a mai eszközökkel még reménytelennek tűnik feltörni. -
Frawly
veterán
válasz
samujózsi
#29329
üzenetére
Onnan fogja tudni, hogy nem hülye. Eladásra szánt diszket kiszednek a gépből és nem hagyják benne. Ha bármilyen gépben olyan háttértárat látsz:
1) amin randomnak tűnő adat van
2) csurig van vele a meghajtó, akár úgy, hogy partíciók sincsenek rajta, vagy egy vagy pár partíció van, és az van tele ilyen adattal.
3) van rajta rendes titkosítatlan partíció és fájlrendszer, de van pár nagyon nagy fájl, amiben megint randomnak látszó adat van.Ezekből rögtön tudod, hogy mivel állsz szemben, egész lemezes titkosítással, partíciótitkosítással vagy konténerfájllal. Ja tudod ki hiszi el, hogy eladás előtt írta felül. Jó vicc. Mondom, ezzel csak azt tudod hülyének nézni, aki tényleg IT analfabéta a dolgokhoz, vagy annyira naiv, hogy hisz még a mikulásban. FBI, CIA, NSA, magyar ügyészség/rendőrség által felfogadott igazságügyi szakértő azonnal fogja tudni, hogy mivel áll szemben. Lehet őket is hülyének nézni, de nem azok, szakemberek ők is, nem most jöttek le a falvédőről.
-
samujózsi
senior tag
válasz
Frawly
#29328
üzenetére
Újra megkérdezem: miből jön rá, azon túl, hogy ő a tolvaj és épp szedi ki a gépből?
Ha odaadja egy vadidegennek, az miből fogja az tudni, hogy értelmes infó van rajta, és nem egy eladásra előkészített, random adatokkal felülírt diszket lát? És ugye nem a dekódoláshoz használt kulcsot kell visszafejteni, hanem a user saját jelszavát, amivel a saját key slot-ját nyitja. Ami egy fokkal egyszerűbb, ha gyenge jelszót használ az ember. (hanyagoljuk, hogy nem használ gyenge jelszót, nem erről szól a történet)
-
Frawly
veterán
válasz
Dißnäëß
#29320
üzenetére
Túlbonyolítod a gondolkodást. Aki nem hülye hozzá, simán rájön, hogy nem dísznek vagy helykitöltőnek tartasz a gépben olyan meghajtót, ami csurig van írva randomnak látszó adattal. Kapásból levágják, hogy micsoda. Ezzel ilyen ECDL Mancika típusú „magabiztos” felhasználókat tudsz megvezetni maximum, ők meg csak annyit látnak belőle, hogy egy particionálatlan (Raw) meghajtónak látszik Windows alatt.
Jól írják, inkább arra menjél, hogy kulcsfájl helyett jelszót használj, jó hosszút, jó bonyolultat, ne oszd meg senkivel, ne írd le sehova. A titkosítási hasht tiktosítás előtt jól keverd meg, hogy jó random legyen, meg írd végig a meghajtót vagy titkosítás előtt /dev/urand adattal, vagy titkosítás után valamivel teleírva, ennek már randomnak sem kell lennie. Ha nem vétesz hibát, az életben nem töri fel senki. Ha van titkosítási fejléc a meghajtón, ha nincs, ha van rajta kamu rendszer, ha nincs, ha van rajta /boot, ha nincs.
-
inf3rno
nagyúr
válasz
Dißnäëß
#29320
üzenetére
Szerintem teljesen felesleges ezzel bajlódni. Nem jelent számottevő plusz védelmet. A titkosításnak kell jónak lenni, aztán nézheti az NSA is, nem tudják feltörni belátható időn belül, ha nem olyan az algoritmus, ami alapból hibás. Valszeg nem is nagyon fognak próbálkozni vele, hanem megdolgoznak egy kicsit, hogy add meg nekik a kulcsot, ha olyasmiről van szó...
-
-
Dißnäëß
nagyúr
válasz
sh4d0w
#29318
üzenetére
Hát, egyrészt ez így van, másrészt fejléc nélküli luks-ról elég nehéz lenne megmondani, hogy az titkosított, annyira random adat, főleg ha előtte teleírtuk a diszket-diszkeket randommal egy dd-vel, majd arra telepítettünk az első 20-30 gigára egy alap rendszert, amit néha használunk is, csak hogy legyen rajta haszontalan "viheted" kategóriájú adat, mögötte meg mondjuk egy free space-re defragolt NTFS/exFAT partíció végig, quickformat módon létrehozva.
Biztosan van tool, ami bizonyos mintákat követve megpróbálja szektorról szektorra beolvasva a teljes lemezt, megállapítani, hogy az a random adat tényleg random adat-e, de azt mondják tőlem okosabbak, hogy IGEN, az TÉNYLEG rohadtul random, fejléc nélkül.
Az meg úgy szvsz még tanult szemnek is fejtörő akkor, mi lészen tovább. (Hacsak nem tesz a fejemhez egy pisztolyt, de arra még mindig ott a truecrypt/veracrypt és az ezzel kompatibilis dm-crypt extension-ök, plausible deniability és társai, de ez már nagyon para, nemérdekel a gyakorlatban).
-
samujózsi
senior tag
válasz
sh4d0w
#29318
üzenetére
Hajnal óta túrom a cvedetails-t és úgy általában a google-t, de nem találom: valamikor az elmúlt 2-3 évben olvastam egy olyan sérülekenységről, ami ellen védelmet jelentett a header hiánya. De nem találom és fogalmam sincs, hogy fakenews áldozata lettem vagy csak most nem találom a vonatkozó infót vagy nem sérülékenység volt, hanem magyarázat az usb-re pakolt header lehetőségére/értelmére. Na mindegy.
Frawly: hogy különböztetsz meg egy random adatokkal (dd if=/dev/urandom of=/dev/sdx ...) felülírt diszket egy header nélküli luks/dm-crypt diszktől? Meg egyáltalán: ha nincs ott a header, ami a kódoláshoz használt kulcsot tartalmazza, akkor mit csinálsz vele?
Ha ott a kulcs, akkor akár brute force is lehet próbálkozni a kinyitásával (a hatékonyságot most hagyjuk ), kulcs nélkül napjaink gépeivel sincs sok értelme. Szerintem. -
-
Frawly
veterán
válasz
Dißnäëß
#29311
üzenetére
De, épp ezt mondom, hogy aki ért hozzá, rájön mi van rajta. Még a fejléc hiányából még a fajtájára is rájön. Azért mondom, hogy ezzel magadat szivatod, csak a saját helyzeted nehezíted meg. Semmi nincs, ha látja, hogy Linux van rajta. Mit tud vele kezdeni? Épp úgy a titkosított részen csak randomnak látszó adatot lát, amit nem tud visszafejteni az NSA sem. Ezzel a partíciómentes, egész lemezes titkosítással csak azokat tudod megvezetni, aki teljesen idióták hozzá. Sőt, még annak a veszélynek is kiteszed magad, hogy aki laikust átvertél vele, az szépen jóhiszeműen particionálni fogja a lemezt, meg formázni, és hiába az USB drive, az adatoknak bukó.
-
Dißnäëß
nagyúr
-
bambano
titán
válasz
Dißnäëß
#29308
üzenetére
a debian telepítője alapértelmezetten tud bootolni titkosított partícióról. minek ehhez usb?
a másik kérdés: ha egy alkalmazás nem támogatja a ha clustert, akkor azt nemigen fogod átteni ha clusterre. olyat, hogy egy san partíciót két helyre mountolj írhatóan, cluster fájlrendszerek tudnak, ha jól emlékszem az ocfs és a gfs ilyen.
inkább azt csináld meg, hogy írsz egy egyszerű programot, ami egy master könyvtárból szétmásolja több alkönyvtárba a fájlokat és ezekre ereszted rá a feldolgozó programokat.
vagy ha nem tudod kikerülni a folyosón a jáva architektedet, akkor az azt fogja mondani, hogy csinálj message queue service-t.
teljesítmény bővítésre mindig a legegyszerűbben járható út először a több ram, utána a nagyobb vas.
-
Dißnäëß
nagyúr
válasz
sh4d0w
#29313
üzenetére
Ezért lesz több belőle, vagy 4... + raw image is fájlba. A detached header-t és key fájlokat is eldugom máshova, így még ha valami csoda folytán mind a 4 USB kütyü + az img is szar lenne, még mindig csak a rendszert bukom max, azaz az OS-t magát, de akár egy Live Linux-al is fel tudom nyitni a konténert.
Illetve ha a /boot nem jó, úgy tudom, be lehet rántani az OS-t még, ennek nem vagyok nagy tudósa még (sosem volt rá szükségem), de .. szóval az OS nem érdekel, az csak úgy elvolna amúgyis. De a storage, amit kezel, legalább megmarad és elérhető és akkor telepítek alá hasonló módon egy új OS-t.
-
haddent
addikt
VPN -es kérdés: Adott egy ipsec v1 aggressive vpn kapcsolat. Megvannak a certek, felh.név, jelszó, p1-p2 paraméterek, minden. Linuxon hogyan tudom működésre bírni? Certekkel ÉS AD/Ldap username+password -del authentikál, AD/ldap -ból lekéri a csoportokat és az alapján ad ip/routing/rules. Sajnos utóbbit, hogy még a certeken felül van xauth sehol nem találok példát..
-
Dißnäëß
nagyúr
válasz
Frawly
#29310
üzenetére
Az utóbbira van szükségem és ember meg nem mondja a random adatból, hogy mi van rajta, utána. Még egy eneszéj sem. Nem mintha nagyon paráznék bármitől, csak ha betörés lenne, akármi, és viszik a motyót, vigyék.
Van még 1-2 plussz módszer amúgyis, amivel aztán még ezt is lehet fokozni, de az már abszolút overkill. Lehet ez is. De ez még vállalható overkill
Arch passz, de rolling release ha jól tudom, a bug-okat nem szeretem.
Debian meg itt-ott kicsit poros, legalábbis a stable, de legalább beton.
Na, így a két véglet után elmondható, hogy egy Debian Testing-el az arany középutat járom
(Kb. Ubuntu szint, mert Ubuntu is testing-re alapul). Nekem bevált. De ez itt már off. -
Frawly
veterán
válasz
Dißnäëß
#29308
üzenetére
Azt nem tudom, hogy a Debian telepítő ezt mennyire tudja, de kézzel biztosan meg tudod csinálni ezt Debian minimal netinstall CD-ről kézzel. Kb. úgy, ahogy írtad, titkosítást létrehozod, meg a boot partíciót USB-n, felcsatolod, és onnan indítod a text mode telepítőt.
Én ennek egyébként Arch-csal mennék neki, azzal tuti megcsinálható. De mint tudjuk, az nem lehet olyan stabi, az csak hobbista debileknek van.
Abban igaza van a másik kollégának, hogy attól, hogy titkosított a meghajtó, még nem feltétlen kell a bootot a USB-re tenni, lehet egy titkosítatlan boot partíció a titkosított lemezen is, egy titkosítatlan részen.
USB hamarabb akkor kell, ha azt akarod megvalósítani, amit írtál, hogy az egész meghajtó partíciók nélkül egy nagy LUKS konténer, és titkosítási headert nem akarsz rá, hanem azt is USB-n tárolod. Nem sok értelmét látom az ilyen trükközésnek, mert aki ért hozzá, úgyis levágja, hogy egész lemezes titkosítás van rajta.
-
-
Dißnäëß
nagyúr
Nnnna, még 4 kérdés.
- Hogyan tudok legegyszerűbben úgy Debiant telepíteni egy rendszerre, hogy a /boot az USB-n van ? (LUKS2-znék /dev/sda-n).
- Netinst elég, vagy full DVD iso, vagy Debian Live alól először megkreálom a titkosítást úgy, ahogy szeretném, szépen bekonfigolom, megnyitom a kötetet és majd erre a /dev/mapper-ben lévő megnyitott kötetre telepítek az installer-rel ?
- Reboot után fel fogom tudni oldani ?
- USB boot-olás után unmount-olhatom a /boot-ot ? (És a feloldott LUKS kötet root-jában lévő akármit mount-olnám /boot-ként ?) Természetesen ügyelve arra, hogy bármilyen HDD-s /boot-ba írást követően az USB-t vissza mount-oljam és átvezessem oda a változásokat a HDD /boot-járól. Például egy apt full-upgrade után, hogy csak egy legalapabb dolgot mondjak.
-
samujózsi
senior tag
válasz
Dißnäëß
#29305
üzenetére
Az biztos, hogy van ilyen, de linuxos változatokkal nincs tapasztalatom, sőt... ha nem jön jobb válasz, próbálj körülnézni a wikipedián, a veritas (vxfs?) és az oracle ocfs oldalán. Előbbi fizetős és talán Solarison láttam működni, utóbbi állítólag gpl, de fogalmam sincs, ha nem oracle rdbms van rajta, akkor mennyire használható. Viszont az oldalán vannak hivatkozások más clusteres fájlrendszerekre, ezért javasoltam kiindulási pontként.
-
Dißnäëß
nagyúr
Kedves Szakik !
Adott egy alkalmazás, RedHat környezet, mely a queue-ját és egyéb hozzátartozó adatokat fájlokba teszeget le, ahonnan egy másik alkalmazás felcsippenti azokat feldolgozásra.
HA-sítanánk, active/active. Létezik valami olyan megoldás, aminek segítségével mindkét aktív instance-be felcsatolható adott SAN storage és mindkét app írhat rá ?
A gond a konzisztencia kérdése, újraírni nem lehet az app-okat, HA viszont kell. NFS néha lebont és döcög, szintén nem opció. Egyéb megoldás esetleg ?
Active/passzív HA-ban a probléma megszűnik, mert egyszerre mindig csak 1 app instance írja adott könyvtárat és ha ez behal, az alatta lévő VMWare indítja azonnal a passzívot és onnantól pedig csak ő ismét.
Teljesítményt akarunk elosztani, ezért aktív/aktív az eddigi elgondolás, bár performancia bővítés nem szükséges, 1 instance is elviszi a motyót.
-
Frawly
veterán
válasz
samujózsi
#29303
üzenetére
Nem azt írtam, hogy garantáltan nem lesz ütközés, hanem hogy „szerintem” nem lesz, és próbáltam megindokolni. Ezek szerint van, tévedtem, beismerem. Próbáltam reagálni a problémádra, mert nem látszott, hogy már kipróbáltad.
Az RO-ként felcsatolt meghajtók mindig szopófaktor, LUKS, LVM, névütközés nélkül is. Általában nem javasolt így csatolni semmit, kivéve, ha nagyon indokolt, hibás fájlrendszer, vagy a célmeghajtón valami kiritikus fontosságú adat van, ami a csatolás nem tehet tönkre, stb.. Először azt hittem, hogy RO alatt itt most ilyen DVD-t vagy hasonlót értesz.
-
samujózsi
senior tag
válasz
Frawly
#29302
üzenetére
Ezt csak azért kérdeztem, mert olyan határozottan állítottad, hogy nem lehet ütközés, KÜLÖNÖSEN mert luks-t használok.
Namost az a gond, hogy az LVM-nek van egy katalógusa/adatbázisa/nevezdaminekakarod, ahol tárolja a metaadatokat, köztük a neveket is. Nem fog kerülőutat csinálni csak azért, hogy UUID alapján elérhető legyen. Illetve elvben igen, mert a vg parancsoknak van egy --select kapcsolója, ahol a vg_uuid=<UUID> segítségével lehet hivatkozni a megfelelő vg-re, de így nem lehet mountolni az eddig talált infók alapján.
Az egyetlen workaround, hogy vgrename <UUID> <új név, ami eltér a meglévőktől>, majd egy vgscan -ay, ha igaz (-ay nem biztos), utána már ott lesz a /dev alatt az <új név>, így már mountolható.
Csak ahogy írtam, akkor van gáz, ha a külső diszk R/O...ui: itthon nem, munkahelyen azért előfordul...
-
Frawly
veterán
válasz
samujózsi
#29301
üzenetére
Igen. Használtam már több disztrón is, a szóban forgó Ubuntun és Archon is, évekig, ráadásul LUKS titkosítással. Ütközéses helyzetem még nem volt vele. Azt nem állítom, hogy garantáltan nincs ütközés, de ezek szerint van, mert kipróbáltad. Egyébként ha felcsatolod egy Live rendszer alatt, akkor át tudod nevezni az LVM csoportokat és köteteket, nem lesz ütközés. Adatvesztés nélkül átnevezhetők.
Read only médiára úgyse tárolnál le LVM köteteket, az ilyenekre fájl/mappaszinten érdemes menteni, nem low level szinten.
-
samujózsi
senior tag
válasz
Frawly
#29300
üzenetére
Ö... láttál már LVM-et? Tisztában vagy vele, hogy működik?
VAN ütközés. A külső diszk nem elérhető UUID alapján sem, amíg át nem nevezem.
(ez most rajtam segít, de ha véletlenül egy read-only médián van, mert archivum... hát az nagy szopás lenne)Az meg külön izgalmas, hogy miután megpróbáltam megszabadulni az átnevezett VG darabjaitól, telefosta a konzolt hibákkal a pvscan, vgscan, lvscan...
- lásd szoktam volt - rég nem programozok)
)
Láttam mindkettőt, egyetemen én szoptam C, ADA, ASM vonallal, másik szakirány röhögött jókat a Java -val. Én tökre értem mit szeretnek rajta sokan, csak azt nem, hogy a Pythonban hogy nem látják ugyanazt csak jobban és többet 
Új hozzászólás Aktív témák
Hirdetés
- Házi hangfal építés
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Asustor NAS
- Sweet.tv - internetes TV
- Gurulunk, WAZE?!
- Teljes verziós játékok letöltése ingyen
- Nyaralás topik
- Macska topik
- bambano: Bambanő háza tája
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- További aktív témák...
- BESZÁMÍTÁS! MSI B550 R7 5700X 32GB DDR4 512GB SSD RTX 3060Ti 8GB Rampage SHIVA MSI 650W
- LG 65C4 - 65" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - 1000 Nits
- Crucial 240GB SSD eladó
- BESZÁMÍTÁS! 2TB Kingston KC3000 NVMe SSD meghajtó garanciával hibátlan működéssel
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest