Abban, hogy ha elgépelek valamit, akkor a hibaüzenetet ki tudom vezetni mondjuk a /dev/null-ba ahelyett, hogy a history_file -ba tegye.
Pl:
command -v ping 8.8.8.8 1>>history.log 2>/dev/null
command -v blabla 1>>history.log 2>/dev/null

Első esetben beírja a ping útvonalát a history.log-ba mert érvényes utasítás. második esetben nem ír bele semmit, mert ugye a halálba küldi. Valami ilyesmi kellene a .bashrc alatt is valahogy, mert ugye ennek minden Enter után le kellene futnia, meg persze érvényes parancs után (az nem baj ha nem kerülne bele a script indítás rossz helyről) az eredeti teljes parancs kerüljön bele a bash_historyba.

Anno mikor zsh-t használtam, abba alapból volt ilyen funkció. A historyba csak azok kerültek bele, amik rendben le tudtak futni. Sokkal áttekinthetőbb a history, ha az elgépelt krikszkrakszok nem kerülnek bele.

[ Szerkesztve ]

Felhasználó függő. Nekem hasznos ha az elgépelt is bekerül hiszen úgy könnyű javítani ha előhívom megint.

Nem feltétlen kell a command-ot használni mert a $? változóban benne van az utolsó parancs státusza.

Jester

Az a baj, hogy ez nem is csak sima script írása lenne, mert ugye ennek már akkor le kell futnia, ha valamit kiadok, ergo a bashrc-ben kell paraméterezni, és szerintem csak ott lehet, ahol a history-t módosítani is lehet minden parancs beütésénél (az tudom, hogy mindig lefut). Viszont ott valszeg olyan megoldással lehetne, hogy ugyanúgy be kell tölteni a teljes historyt, és az utolsó sort (ami az uccsó parancs lenne) arra ráengedni a command -v -t vagy a type-ot, és ha hibát reagál rá, akkor ezen utolsó parancs törlése, ha nem hibát ír ki, akkor a historyba való engedélyezés. Nah ez nekem viszont már túl bonyolult

Nem próbáltam, de ha más nem fut a parancs meg a history hook között akkor a $? még mindig jó és csak az utolsó sort kell törölni.

Jester

Lehet csak pongyolán fogalmazok, én hardveres RAID-ről beszélek. Szoftveres RAID-et, meg ZFS poolt, azt valóban lehet bárhova tenni rétegügyileg, ahogy az LVM-et is. Gyanítottam a kollégának hardveres RAID van a LUKS rétege alatt, de abban igazatok van, hogy nem kéne látóasszonykodni, amíg nem tartalmaz a kérdés minden lényeges adatot, addig nem kéne próbálni konkrét választ adni.

Scriptben végülis megírtam. Jó favágó módszer, de mükszik:

program=$(tail -n 1 pelda.txt)
ertek1=$(type $program)
ertek2=$(echo $?)
if [ $ertek2 -eq 1 ]; then
sed '$d' pelda.txt > tmp.txt && mv tmp.txt pelda.txt
else
exit 1
fi

Viszont hogy ezt hogy futtatom minden parancs kiadása után, arról fingom sincs. Mert az ok, hogy a history duplikációs törléses megoldás lefut minden parancs kiadása után, de az a .bashrc-ben van. Viszont a .bashrc-t nem tudom mi alapján nézi, mert ott se minden fut le minden parancs kiadása után. Van ami csak a terminál indításakor. Így most megakadtam.

bambano találta fején a szöget, de én fogalmaztam hiányosan lehet.

ZFS raid-ezek, csak ott ezt nem raid-nek hívják, hanem raidz-nek, mirrornak és stripe-nak, de lényegében user szemszögbôl mint funkcionalitás, raid.

Nem akarom egyelôre a zfs beépített encryption-jét használni, azt szeretném, ha random szemétnek látszana minden HDD tartalma, erre a LUKS2 képes, ha a titkosítás header-öket máshol tároljuk.

Szóval:
1. HDD-k LUKS2 titkosítása
2. Az elôállt mapper device-okkal (amire a fájlrendszer kerülne) ZFS pool-ok építése.

Az érdekelt, hogy fizikai HDD hiba, bad sector esetén mit lát az ember a mapper device-on. Bad-ként megjelöli, vagy mi lesz pontosan. A zfs legfelsô layerként ezt lekezeli szépen (mirrorom és raidz1-em egyaránt van).

POKE 16017,44 ..... SYS 2077

minden réteg annyit lát, amit az alatta lévő réteg, számára értelmezhetően megmutat.
ha az alsó réteg úgy működik, hogy "majd én megoldom a hibákat", akkor a fölötte lévő soha nem fogja megtudni hogy bármi történt, még föntebb még esélytelenebb.

ha a fizikai réteg fölött lévő akármi lekezeli a hibát, átrakja az ott lévő adatblokkokat valami egészséges helyre, arról a fölötte lévő réteg nem fog tudni, miért is tudna, nem ő kezeli, nem is találkozik a fizikailag hibás szektorral, az ő általa látott eszközben már nem fog mutatkozni a hiba, hisz' azt lentebb kezelésbe vette az ottani réteg.

és ez valójában így is van jól.
ha 2-3-10 logikai réteggel föntebb is látszik egy fizikai hiba, ott nagy gebasz van.

[ Szerkesztve ]

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Tudtommal normál esetben a bad sector jelölés íráskor kerül rá a sectorra, ezért nem okoz problémát.

Ez tiszta és világos, csak nem a kérdésre adott válasz.
De jó, ha mások is tudják.

Tehát újra: HDD-n történik valami és lesz 1 bad sectorom, amirôl az OS tudomást szerez. Ahogy történt is nemég, ami el is tûnt magától (HDD firmware pótolta spare tartományból, zfs meg korrigált scrub során).

Ezt a hibát egy ntfs, egy fat, akármi, felvenné azaz megjelölné rossznak, normál esetben. Csakhogy ott LUKS "szemét" van, ergo a feloldott mapper device-on megjelenítôdik vajon a hiba ? Hogy a zfs lássa.

Mert ha egy fizikai szektor sérül, HD sentinel is jelzi, az a LUKS titkosított blokk, ami ehhez tartozik, szintén sérülni fog és feloldhatatlanná válik, emiatt - feltételezném - a mapper device-on is a legkisebb logikai egységnyit hibaként fog betudni a rendszer, az ezen ülô zfs meg majd a többi HDD + checksum -ok segítségével pótolja az adatot, máshol elhelyezve azt.

De lehet nem ez történik, csak gondolkodom hangosan. A sorrend biztosan az, hogy amit egy réteg elrejt, elmaszkol, a felette lévô nem lát, ez vili. A lényeg pont az lenne, hogy lássa.

POKE 16017,44 ..... SYS 2077

De válasz a kérdésre, csak nem értelmezed. A HDD-n kelekezik hibás szektor. Esetedben LUKS-on fut ZFS zraid, ezek közül a LUKS-on már adatvesztés lehet, de a ZFS zraid redundanciával lehet ezt ki tudja védeni, ha újraépíted a tömböt.

De ha nem ez lenne a felállás, akkor az OS nem is tudna róla, hogy hibás szektor van, mert egy alsóbb réteg gondoskodna a hibajavításról.

A HDD íráskor jelöli bad sectornak. Ha időközben lesz hibás az adat azzal a HDD nem tud mit kezdeni általában.

Szerintem ugyanazt beszéljük, mert én végig ezt mondom... HDD hiba, LUKS adatvesztés, ZFS meg resilver és kész, illetve ha pont rámegy, elvileg még auto-healing is, de nyilván resilverezem, ha épp úgy jön ki, hogy meglátom. (HD Sentinelre néztem rá, 1 bad volt 2 hete vagy 3-4 napig, 100/99, aztán visszajött 100/100-ra. Na mondom mi ez ? Resilver, checksum hiba, javítva. Megköszöntük neki, vállvonás. Csak egy LUKS-ot közbeékelve -integrity kapcsoló nélkül (dm-integrity), mivel a ZFS pont erre való, akartam megtudni, vajon mi lenne, ha.

Akkor lényegében értve vagyunk.

POKE 16017,44 ..... SYS 2077

Olvasáskor nem ? Mert mondjuk azt nem kell tudnia, mi van a hibás szektoron, de annak ténye, hogy ott valami nem oké a fej alatt egy ponton, mikor elsuhan alatta párszázszor, szerintem azt képes lenne detektálni. Lásd HDSentinel Surface Scan, Read mód. Lazán pakolgatja be nekem a feketéket egy szar vinyón.

Mondjuk nem WD Purple (ahol nincs firmware szintű CRC), hanem Seagate NAS, ahol meg van.

Na mindegy, azt hiszem, a lényegre választ kaptam, tehát LUKS mellett egy adott titkosított blokk úszik, leves, a ZFS meg erre ugyanúgy megoldás innentől, mintha LUKS nélkül válna valami alatta inkonzisztenssé. Jó. Kiváló.

[ Szerkesztve ]

POKE 16017,44 ..... SYS 2077

A HDD nem jelöl meg semmit. A HDD-n lévő vezérlő tudja detektálni, ha egy szektor hibás, akkor általában tud cserélni a tartalék területről, egy másik szektort befog helyette (reallocated sector). De ilyen reallocated-es HDD-t már szerveres felhasználásnál nem szoktak megbízhatónak minősíteni, pedig adott esetben még évekig működhet. Az, hogy van-e reallocated szektor, azt a SMART-ban lehet megnézni.

Hagyományosan a rossz szektort az OS is tudja detektálni, hogy az írási-olvasási műveletekre nem jön vissza adat. OS függő, hogy ilyenkor milyen megoldást alkalmaznak. Linux nem csinál semmit, de meg tudod jelölni a szektort fsck futtatásával, olyan opcióval, hogy végigteszteli a meghajtó felületét, és a rossz szektorok listáját frissíted vele. Ugyanezt csinálta a DOS, de az csak formázáskor. A Windows valószínű meg tudja jelölni hibás szektornak, lefuttat rá egy belső scandisk-et, és a fájlfoglalási táblákban nem használja ezt a szektort, kivezeti az erre hivatkozó bejegyzéseket.

De más rétegek is detektálhatják, hogy adatvesztés volt, ha nem stimmel valami checksum, parity, más integritásmutató.

"...De ilyen reallocated-es HDD-t már szerveres felhasználásnál nem szoktak megbízhatónak minősíteni..."

Ez egészen konkrétan nem így van. Nem véletlenül használnak a szerverekben RAID-et, az operátorok meg nem ugranak minden SMART hibára, akkor lépnek közbe, ha a monitoring közli, hogy egy diszk döglött, vagy rossz a kondíciója. Ilyenkor vagy automatikusan, vagy manuálisan egy spare egység kerül a helyére, rebuild a RAID-re és ennyi.

https://www.coreinfinity.tech

HDD-n lévő vezérlő Ami ugyan úgy a HDD része, mint a tányér, a fej, meg a motor Egy bad sector miatt sehol nem fognak HDD-t cserélni.

Ami tudja detektálni magától az adat sérülést azok a checksumozó fájlrendszerek, vagyis a Btrfs és a ZFS.

Jó, de a hibás szektor nem jelent automatikusan rossz kondíciót? Nekem úgy rémlik, hogy HDSentinel nagyon lehúzza a HDD-t emiatt...

[ Szerkesztve ]

Buliban hasznos! =]

Itt nem hdsentinelről beszélünk, hanem olyan szoftverekről, amelyet a gyártó kifejezetten a lemezhez írt. Egy bad sector kutyafüle, átallokálja a vezérlő a spare területről, majd tesz egy SMART bejegyzést, hogy megcsinálta, de addig senki nem foglalkozik ezzel, amíg megy a lemez.

A hdsentinel meg mondta nekem hdd-re, hogy 40%-os, még évekig használtam adatvesztés nélkül.

https://www.coreinfinity.tech

Nekem van olyan HDD-m amire kiírja, hogy 70 százalakos, mert egyszer egy hibás sata kábellel volt rákötve az alaplapra és keletkeztek kommunikációs hibák. Azóta is megy vagy 5 éve. Asszem egy bad sector is van rajta

Igen, nálunk is így van. Ott a spare, vállvonós sztori. Aztán az ember cseréli, amikor felállt a wc-ről kényelmesen és leslattyog a terembe, még maintenance window sem kell hozzá.

POKE 16017,44 ..... SYS 2077

Igen, meg a ReFS most Windows-ban ha jól tévedek, de még "kísérletinek" mondanám W10-ben.

[ Szerkesztve ]

POKE 16017,44 ..... SYS 2077

Hát utal rá, nyilván nem egészséges az olyan kütyü, amin megjelenik 1-2 hibás szektor, de ha poreszt tárol polcon, nem téma, ha pedig logikai rétegekben van megoldva ennek a hibának az áthidalása, szintén nemtéma. Azonnal nem temetném.

Mindjárt megnézem, mennyi a reallocated sector count-om a "gyógyult" HDD-mre.

POKE 16017,44 ..... SYS 2077

Nekem az ADATA SSD-m ilyen, szar SATA kábel miatt (még vagy 6-7 évvel ezelőttről, jó régi) szalad ugyanolyan értékekkel ma is hibátlanul anyám laptopjában. Már nem rugózok rajta, hogy kiüssem a logot, vagy ilyesmi.

POKE 16017,44 ..... SYS 2077

Pedig hasznos lenne, mert így kevésbé tűnik fel, ha megint kifogsz egy hibás kábelt.

Buliban hasznos! =]

Erről nem is tudtam, remélem nem sokára használható lesz. A checksuming elég hasznos feature. Főleg SW RAID1 esetén.

Igen. Nekem a W10 VM-ben fut ugyan, de van az a felhasználás, amikor jól jöhet. Mindeközben a ZFS Windows-os portján is dolgoznak állítólag, hogy milyen tempóban, passz.

----------------

10 reallocated sector-om van 2db HDD-n is, a 6-ból.
(5db Seagate NAS, 1db WD Purple).

A Seagate-eken 100 lehet ezek száma (legalábbis HDS szerint, de lehet rosszul értelmeztem az oszlopok leíróit), a Purple-ön 200.

Hááát... ééérdekes. De amíg nem szaporodnak, zümmögjenek csak.

Régen volt gyenge minőségű táp miatt is több HDD-vel gondom, mire rájöttem, hogy bakker, mi van, ha táp. Nem gamer config volt, hogy elfogyott erőben, hanem szimplán valami nem volt kerek, kicseréltem (nagyobb VGA miatt) és eltűntek a hibák, én meg pislogtam, ez most mi volt. Aztán raktam csak össze.

De a mostanim egy 500W FSP, VGA elhanyagolható (GF 710), kifogástalan, a NAS vinyók futottak eleget már, ezt tudom, szóval nem lepődök meg, csak ez, hogy bejelzett pár hete és 1 hétig ott volt a 99% aztán visszagyógyult, érdekes jelenség volt. Két manuális scrub-omba került, pusztán intuitív alapon. Egyik a bejelzés után, másik pedig akkor, mikor visszagyógyult (hiszen mindkettő változással jár). Mindkétszer hozta a CKSUM hibát és korrigált is a ZFS.

Jól elvittem a témát, sry mindenkitől. És köszi, hasznos kis duma volt.

POKE 16017,44 ..... SYS 2077

"A Seagate-eken 100 lehet ezek száma (legalábbis HDS szerint, de lehet rosszul értelmeztem az oszlopok leíróit), a Purple-ön 200."
Ez normalizált érték tresholdja, amit a gyártó algoritmusa alapján számol raw-ból... szóval többnyire értelmetlen összevetni, almát körtével.

Tegnap még működött...

Tényként írtam felsorolás szerűen, egyértelmű, hogy itthonra NAS célra jobb a Seagate. A Purple kényszer vétel volt, valóban alma és körte.

POKE 16017,44 ..... SYS 2077

Igen, ebben biztosan igazad van. Hagyják benne a tömbben a marginálisan jó lemezt, növelve az esélyét, hogy egyszerre több diszk is kidögöljön a tömbből. Mert egy ilyen diszket benne hagyni felesleges rizikó. Azt értem, ha tönkremegy, akkor cserélik, és újraépül a tömb, de nem kell megvárni, míg kileheli ténylegesen is a lelkét, azért van a SMART kitalálva, hogy lépni lehessen már akkor, amikor gyengeségek mutatkoznak.

Nem, a hibás szektor nem jelent rossz kondíciót. Főleg, ha a vezérlő nem detektálta a hibát még. HDSentinel minősítései kb. semmit nem érnek, csak tájékoztató jellegűek. Sokszor irkál totál baromságot. De maga a SMART se ér sokat. Jelezhet előre meghibásodást, de sokszor van, hogy semmit nem jelez, 100%-osnak látszik a meghajtó, semmi hibára utaló bejegyzés, vagy attribútum, erre egyik napról a másikra megdöglik és tégla lesz belőle. A SMART csak egy ilyen +1 védelmi vonal, ami esetlegesen jelezni tud. Plusz ma már egyik tároló sem megbízható, mióta agyonolcsósították ezeket, redundanciának és/vagy biztonsági mentésnek mindig lennie kell, utóbbi még user errornál is jó, ha valaki beszop egy ransomware-t, vagy letöröl/felülír valamit véletlenül, akkor legyen hova nyúlni, ne bőgés legyen, hogy jajjazadataim, azonvoltanemtudomén, pótolhatatlan, brühű.

[ Szerkesztve ]

Mivel korábban dolgoztam ilyen környezetben, valószínűleg jobban képben vagyok vele.

Nem kell elhinned nekem, menj fel a hupra és nézd meg, az ottani rencergizda hány kidőlő diszket posztolt.

https://www.coreinfinity.tech

nem tűnik egy űrtechnológiának a logrotate, mégse működik jól nálam
[root@Echo-Five logrotate.d]# cat remote
/var/log/remote/*/*
{
rotate 90
daily
missingok
compress
}

ez nálam azt csinálja, hogy rekurzívan hülyére csomagol dolgokat és ez lesz az eredmény

csak ebben a mappában 60.000 fájl van.

miért?

[ Szerkesztve ]

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

/var/log/remote/*/*

Ez a baj, ez mindenre matchel. Esetleg helyette:

/var/log/remote/*/????-??-??

Amúgy good practice a log fájlt ellátni valamilyen mondjuk egy .log kiterjesztéssel. Azzal nem lesznek ilyen problémák.

[ Szerkesztve ]

köszi, módosítottam az rsyslog konfigot, hogy .log kiterjesztéssel hozza létre a fájlokat, meg a fenti konfigot is, hogy /var/log/remote/*/*.log-ra matcheljen, aztán meglátjuk

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

nem kellene kizárni, hogy a * /-re is matcheljen?
én valami ilyesmivel kísérleteznék:
/var/log/remote/[^/]*/*.log

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Szerintem a logrotate wildcard kezelése elég buta. Nem tud ilyeneket.

Sziasztok Szakik !

/boot milyen gyakran frissül ? Nagyjából nagyon ritkán, jól sejtem ? Ahogy a boot folyamat elején megvan a gyökér könyvtár az OS-el (ami másik eszközön lenne), lényegében /boot el van felejtve, stimm ?

USB eszköz lenne. Boot folyamat végén automatikusan át-mount-olva az OS gyökerében lévő /boot könyvtárba és kihúzhatom a stick-et a gépből.

Mi az, amire ügyelnem kellhet egy ilyen esetben ?

Amit eddig látok:

1. 2-3 USB eszközöm is legyen, identikusak. (Elég fájl szinten, nem kell dd, igaz?)

2. apt full-upgrade és hasonlók esetén a boot-ban lévő dolgok is frissülhetnek, ha mondjuk jön le egy új kernel is.. ez az OS diszken lévő /boot könyvtárban le is megy, majd végül átmásolom ezt a visszadugott stick-ekre és jó vagyok, stimm ?

Kubuntu, uefi.

POKE 16017,44 ..... SYS 2077

A bootban van a kernel és az elég gyakran frissül. Nem teljesen értem mit akarsz és miért...

Szimpla minimális adatvédelem. Működő gépet ha bekapcsolva hagyok itthon, és elvinnék, max a hardver miatt izgulok, az adathoz nem tud nyúlni, nekem pedig van lakáson kívül más helyen backup-om a legfontosabbakról.

POKE 16017,44 ..... SYS 2077

Erre vannak bevett, értelmes megoldások. A /boot pendriveon tartása elég hülyeségnek hangzik.

Én jobban szeretem a titkosítási kulcsaimat és a diszkek luks2 header-jeit ezeken tudni, ha pedig ki van kapcsolva a gép, a nyakamban, zsebemben, pénztárcámban. Természetesen az usb is titkosan, csak jelszóval nyílik, de ha kinyílt, utána automatikusan nyitja az összes diszket tovább a header-ök, key fájlok segítségével. (Ezekről van backup-om felhőben is veracrypt konténerben, meg emailben is magamnak elküldve, nem gémél).

Arra nincs igényem, hogy távolról is újraindítható legyen, bár van csilivili router-em és dinamikus dns és WOL, ez most nem kell.

Ez egy desktop gép, amolyan szerver is, home lab, nevezzük akárminek, nem egy dedikált 7/24-es klasszikus szerver (de gyakran van bekapcsolva napokat. Nem mindig, de gyakran). És az egész eddigi IT-s életem rajta kb. (Cold backup van kettő is).

POKE 16017,44 ..... SYS 2077

és amúgy mekkora az esélye, hogy ezt
a, ellopják
b, olyan lopja el, aki nem adja le azonnal a méhben, amint rájön, hogy nem a megszokott kék ablak alatt kezdenek körözni a pöttyök?

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Nem túl jó a környék, ahol lakok, földszint, nincs bizt. ajtó sem és minden ablak utcára is néz, egyik egyikre, másik másikra. Bár egy központi lécsőházajtó van, de na.

Ha meg tudja, mi van a gépben és nem egyből a MÉH-be megy vele, akkor nyert 6x4TB diszket és egy SSD-t, egészségére, már pattinthatja is fel rá a partíciókat és használja, amire tudja, vagy eladja, stb. Nem hinném, hogy a kvantumszámítógépek holnapután kezdenének terjedni mainstream-ben. (Ha pedig igen, addigra majd kvantumtitkosítunk).

Egyszerűen csak így vagyok nyugodt, ennyi. Az érdekelt volna, hogy ilyen kernelcserés upgrade-ek során valami boot loader (uefi-vel nem vagyok annyira tisztában) is frissül-e, vagy csak a fájlok /boot-ban és kész.

POKE 16017,44 ..... SYS 2077

yubikey-t ismered?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nem. Már olvasom is, klassz Köszi !!

POKE 16017,44 ..... SYS 2077

ez it a profik területe. hát én nem vagyok az. viszont lenne egy kérdésem. tud valaki egy használhato zenelejátszot, jukeboxot? mert eddig nem találtam. mindenhol csak az a husz használhatalan szutyok találhato ami semmire sem jo. sok keresgélés után találtam egy helyet ahol volt még 200. de azoktol sem lettem elörébb. a közös jellemzöjük az volt hogy az egyik szar volt a másik meg fos. wmp9 pont megfelelö lenne linuxos verzioban. a követelmény vegye fel a zenék tárolohelyét. és külön a listákat. pont ahogy a wmp9. nem hittem hogy ez annyira bonyolult.

Foobar, én nem tudok lejönni róla. (Mondjuk nem egy csicsa cucc, tény, de k* jó).
Debian XFCE alatt is, Ubuntu alatt is, Kubuntu alatt is.. bárhol igazából, ilyen nagyobb disztrókon.

sudo apt install snap
snap install foobar2000

Utána lehet tologatni alá a plugineket ezerrel. Foobar alatt a virtuális Z: meghajtó a linux / könyvtára, onnan meg már rendben vagy. A felületet érdemes jól személyre szabni, rommá lehet konfigolni.

[ Szerkesztve ]

POKE 16017,44 ..... SYS 2077