Příspěvky

316

Hardware / Re:Výkon čtení disku a komprese v NASu (A53 4jádro) - hodnoty

« kdy: 09. 12. 2021, 17:19:09 »

Důvod nepoužití těch utilit, je lenost +  že to právě běží na NASu, s vlastním "os", kde není ani smartmontools (získávání smart je tam zrůdnost a hdparm je osekaný, neumí -M) , apt, dpkg, pacman, yum a nepřipojen k internetu, takže používám "co dům dá". 

Asi si ho stáhnu  a  zkopíruji do sbin/ stejně jako nepodporaný exFAT co tam "neměl podporu".




Proč by to nemělo být "uložené" sekvenčně? Opakuji, nebudu kopírovat soubory, ale blokové zařízení. Zdrojová data z podstaty budou sekvenčně čtená a možná snad je obava u těch zapisovaných, ale tam jsem myslel, že pomůže buffer a velké bloky, kdy na disk se vychrlí vždy blok o 100MB třeba a i tím bude zajištěné, že buď se zapíše krátký komprimovaný blok a nebo se 1:1 zkopíruje "nekomprimovaný" ( poněkud binárně řečeno- komprese g/zip jak ji známe přece  precuje někde mezi)

A nebo se poohlédnu po již hotovém řešení...


Přitom by mi stačilo  to jednoduché řešení - nulové bloky to zapisovat nebude a nenulové to zapíše celé (akorát otázka je vhodná velikost bloku něco mezi 4MB a 512MB?) a zápis nějaké "bitmapy" obsazení.

Účel: v podstatě mít možnost přistupovat k 10TB disku velice rychle. Ale nemám peníze na nákup 10TB SSD. Proto chci disk přečíst předem (cca 10-15 hodin) a uložit ho bez nul, což dle odhadu bude 25% max. a pak se v něm pohybovat. (A  nebo aspoň udělat bitmapu, ze které uvidím hned, kde jsou ty bloky rozmístěné)

317

Hardware / Re:Aky disk do NASu?

« kdy: 09. 12. 2021, 17:09:15 »

A kolik ten starý Enterprise disk žere elektřiny ? Když to bude o 10W víc než nový (což u výkonný Enterprise disků nebude problém), tak to bude rázem cca 500 Kč ročně navíc na každý disk za provoz.

Mimochodem ty heliové disky mají menší spotřebu než srovnatelné normální. Helilum není vodík, uník zjevní není takový problém. Ono v tom disku není žádný přetlak, takže to helium nemá "motivaci" někam unikat.

Tak především Helilium ani není Helium. Uník nezávisí na srovnání(rozdílu) s atmosférickým tlakem 100kPa, ale s tlakem Helia v atmosféře , což je jiné (ale netvrdím to jistě, myslím, že by se k nim mohly připočítat plyny s nižší nebo vyšší úníkovostí(velikostí molekuly), ale ne vyšší). Našel jsem že ve vzduchu ho je asi 5ppm, takže asi nula nula nic.

Nikde jsem nenašel tlak Helia v discích, ale důležitý je i to, že ve vypnutém disku logicky bude rozmístění (a tlak) homogenní, ale v běžícím prý jiný (v závislosti na vzdálenosti od středu plotny logicky) a rozdíl může dělat prý až 2700mmHg..

Co se týče srovnání spotřeby (enterprise držák, moderní úsporný), nemá cenu se ptát na spotřebu toho starého, ale na rozdíl spotřeb.. A jestli to vychází na 4W v idle a 6W v zápisu, pak to je opravdu zanedbatelné za rok (4*5*8=160Kč) (4W, 5 Kč/kWh, 8=365*24/1000)

S spotřeba disku vs spotřeba ze sítě??? To si taky myslím že je pod rozlišovací schopnost. Max 20%. Navíc Když už NAS samotný běží...

318

Hardware / Re:Výkon čtení disku a komprese v NASu (A53 4jádro) - hodnoty

« kdy: 09. 12. 2021, 08:45:41 »

Pardon , dohnalo mě Copy Paste jako Maláčovou. Sorry, hledal jsem ve slovníku... Nejdřív jsem myslel, že jde o inkontinenci.  Test s gz byl samozřejmě bez "of->null".
A jen poznámka na okraj, měřil jsem to i s "před"příkazem time a i | dd of, abych měl přehled o množství dat na vstupu i výstupu

Kód: [Vybrat]

[root@nasturbace #]$ time dd if=/dev/sda bs=1M count=160 skip=4000000 | gzip -1nebo9 -c  | dd of=/dev/null

### skoro prázdná oblast
160+0 records in
160+0 records out
167772160 bytes (160.0MB) copied, 6.811203 seconds, 23.5MB/s
real    0m 6.81s
user    0m 0.00s
sys     0m 0.62s
319+1 records in
319+1 records out
163592 bytes (159.8KB) copied, 6.817881 seconds, 23.4KB/s

### neprázdná oblast (pozor, osmina velikosti)

sudo time dd if=/dev/sda bs=1M count=20 skip=19000 | gzip -c -4  | dd of=/dev/null
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 5.780149 seconds, 3.5MB/s
real    0m 5.78s
user    0m 0.00s
sys     0m 0.06s
40925+1 records in
40925+1 records out
20953927 bytes (20.0MB) copied, 5.807068 seconds, 3.4MB/s

Holt asi na to budu muset použít i7... I komprese prázdného místa jede 20MB/s

A ještě nějaká rada, když chci aby byla utilizována maximální rychlost čtení i zápisu, vyplatí se to nějak "bufferovat do RAM", pokud by byl druhý(nebo i první) disk pomalejší? (S přihlédnutím, že občas se tam najde blok nul a tím pádem by se výstupní disk mohl chvíli flákat) . Že kdybych použil "mezi" pipami něco jako dd if | docasnybuffer14GBRAM |dd of.... (Vykládám to lapidárně)

2.) komprese gzip  dd if=/dev/sda of=/dev/null bs=1/2/4M | gzip -1/-9 >/jinydisk/outfile.out

Co tady tou inkantací přesně myslíte

Sorry, hledal jsem ve slovníku... Nejdřív jsem myslel, že jde o inkontinenci.

319

Hardware / Re:Aky disk do NASu?

« kdy: 09. 12. 2021, 08:16:42 »

MG04

No ta cena není zlá (hlavně je nový z obchodu a se zárukou, což je u disků kruciální), ale jde o starou řadu už (kapacita je subjektivní a někdy ty poloviční kapacity musí kupovat, příští rok už třetinové). Myslím, že se doprodává 07, aktuálně je 08 a MG09. Důležité je že až od 07 jsou plněné balónky héliém.

320

Server / Podpora exFAT u QNAP: ARM vs. x86

« kdy: 08. 12. 2021, 15:11:07 »

Jak je to s podporou exFAT na QNAP NASech? Píše to, že mám si koupit nějakou licenci. Přitom informace jsem se dočetl, že podpora je zabudovaná, ale pro x86 procesory..


-Opravdu jen pro x86(64) procesory? Pro arm je to mimo hru (ale očivině to není technický problém, když stačí zkopírovat  binárku, ale otázkou je výkon a mód-kernel/fuse) .
-Jaké to má politické vysvětlení?
-Existují i jiná "podobně" "genitální" omezení? Například že třeba z podpory jsou vyloučeny disku podle druhu (disk v šachtě NASu vs připojený přes USB) nebo nad určitou velikost?

321

Hardware / Výkon čtení disku a komprese v NASu (A53 4jádro) - hodnoty

« kdy: 08. 12. 2021, 15:07:05 »

Jaké bych měl očekávat hodnoty výkonu v NASu s 64bit procesorem ARM  A53 čtyřjádro.  Má 2 sloty pro sata iii i disky se hlásí  jako v režimu SATA 6Gb/s ("in use").Spíš tedy bych chtěl zhodnotit zde napsané hodnoty:

1.)
rychlost  čtení disku dd if=/dev/sda of=/dev/null bs=1/2/4M .....155MB/s, 145 u konce kapacity 10TB

Disky by měl umět >220MB/s.

2.) komprese gzip  dd if=/dev/sda of=/dev/null bs=1/2/4M | gzip -1/-9 >/jinydisk/outfile.out .... 4 MB/ s!!!!!!!!!!!!!! (nebo případně ...gzip -c || dd of=soubor-jinydisk) To je nepoužitelné, já potřebuji opět stovky MB/s


Prosím o nějaké tipy čím by to mohlo být... u 2.  ještě musí vyzkoušet víc faktorů (of=/přímo-partition-sdc3) - především se zapisuje na disk USB3.0  a ještě ve filesystému exfat, který jsem tam musel dodat ručně (mount.exfat do /usr/sbin) a ručně připojit

322

Server / Re:Mail u sebe doma

« kdy: 05. 12. 2021, 17:43:59 »

Já to pro jistotu zopakuju a vyhledal jsem si odkaz v tomto vlákně: (samozřejmě doufám že se myslím IP adresa odesílajícího SMTP serveru a ne samotného uživatele  )

Dodržujte tyto doporučené postupy pro poštovní servery, které odesílají e-maily uživatelům Gmailu:

Ověření záznamu PTR odesílajícího serveru
Důležité: IP adresa odesílatele musí odpovídat IP adrese názvu hostitele uvedené v záznamu PTR. Záznamy PTR se nazývají také reverzní záznamy DNS.

IP adresa odesílatele musí mít záznam PTR. Záznamy PTR ověřují, že název hostitele odesílatele je propojen s jeho IP adresou. Každá IP adresa musí být v záznamu PTR namapována na název hostitele.

A co ti domácí uživatelé, kterým provider dokáže změnit PTR . Těm závidím a závidíš? Nebo takový provider "domácí přípojky" to nesmí změnit (a kdo mu to přikazuje a kdo to hlídá vymáhá a pokutuje)?


Co tedy znamená správný PTR ? Já měl za to, že správný PTR je takový jako "doména emailové schránky odesilatele od kterého přišel mail" . Pak tedy nechápu vyjádření i když máte správný PTR záznam .... jehož PTR obsahuje číslice Tím jsi myslel  opravdu vzácné příklady jako domény gifts4you.com nebo 123autobazar.cz nebo  98-12.brno-venkov.cz?

A kruciální otázka k poslednímu odstavci:
Pokud tedy jméno serveru nemusí nijak souviset s doménou:
1. Není to ve sporu s tím citovaným úryvkem nápovědy google
2. Jak je pak řešena triviální obrana, že někdo z tramtárie posíla poštu jménem @policie.cz . Zkusím si odpovědět sám - přeci SPF záznamem (který "uložil policejní ajťák " "na doménu" policie.cz do TXT políčka  )
3. Ano, takové případy v praxi existují - ten zmíněný email.cz na vlastní doméně a nebo z jiného soudku velké e-shopy, co outsourcují odesílání infomailů na "velké (spammerské) ryby" jako list-manage, ecomail atfuj.
4. K čemu tedy to "šílenství" s správným PTR, když to není ochrana a řeší to lépe SPF nebo DKIM (stačí jedno z toho)

323

Server / Re:Mail u sebe doma - smysl PTR , natož u hostérů pro víc domén

« kdy: 03. 12. 2021, 21:29:28 »

Toto téma mě zajímalo a nebýt teoretických exhibicí  některých  potrefených hus, šlo by i o hodnotné informace a rady, které jsou takto přehlušeny hýkáním a argumentací na slaměnné panáky.

Co mě ale zajímá konkrétně proč se tak lpí na "správné hodnotě PTR záznamu" a jaký je jeho význam pro (bezpečnost) e-mailu. A řeší se PTR pro směr ven(odesilatel, posílající sere) nebo dovnitř (smtp server pro příjem). Já si myslím, že pro první směr (ven), ale klidně mě opravte. ...A tedy znamená to, že je to nějaká další pojistka aby mail nemohl odesílat kde kdo, kdo má doménu, ale musí to být posvěcené providerem (který má v moci změnu PTR)?


A to hlavní, jak velký problém toto pravidlo PTR vytváří pro případ, kdy mailingová společnost (nebo hostér mailu) používá typicky jeden odchozí mail server, ale hostuje stovky domén(zákazníků, firem).
Z podstaty věci PTR záznam je je unikátní mapování z IP na PTR hostname No a to jako seznam.cz třeba má jako pro každou doménu post,email,seznam mailserver(y) s více IP adresami  (nemusí to být nutně více mailserverů, může mít přiřazeno více IP). To se mi zdá absurdní a že mám v úvaze někde chybu. Jako 77.75.1.1 bude mít PTR pro email.cz, 1.2 pro post.... A to nemluvě o Email Profi na vlastní doméně, těch bude tisíce. Nebo  tenhle problém 1:1 PTR záznamu pro potřeby obsluhování více odchozích doméén jedním mailserverem ( N:1) řeší SPF?

(Úplně tuším přesně, který teoretik mi odpoví a dopředu děkuju, pokud odpoví, na to co jsem se ptal a né že to dělat nemám. Ale na rozdíl od původního tazatele se ptám teoreticky)

324

Software / Re:Linux - informace o vytížení disků

« kdy: 02. 12. 2021, 20:56:43 »

Já jen doplním, že více user friendly bude iostat -xhd 5. (h=násobky jednotek, d:počet sekund )

325

Software / Re:Výcuc 10TB disku, většinou nuly

« kdy: 02. 12. 2021, 20:54:04 »

Děkuji za obsháhlé odpovědi, možná jsem moh upřesnit na začátku, že s největší pravděpodobností na tom disku nic nebude/nic neočekávám, ale mohou tam být nějaké zbytky. Takže neočekávám nějaký filesystém, ale chci se podívat co zhruba na disku je, případně kdyby tam byly signatury nějakých souborů.

326

Software / Výcuc 10TB disku, většinou nuly

« kdy: 29. 11. 2021, 17:10:28 »

Půjde pro přečtení disku

Kód: [Vybrat]

dd if=sda conv=sync,noerror iflag=direct,fullblock bs=1M | pv  -S -s 12345G | gzip -c image.bin

použít... Odhaduji že z 10TB disku to bude max 2TB. Bude dobře gzip fungovat na mnohagigabitové série nul ?
Ale nevím ,jak to  bude v praxi fungovat, když pak se budu chtít na obraz podívat. Existuje nějaký program, který mountne  velky gzip soubor transparentně? (pro windows Imdisk - umí načíst krásně iso soubor a pracovat s ním jako s novou jednotkou)

Rozhodně nechci procházet disk opakovaně. Nebo poradíte nějaký free tool, který by udělal chytře obraz (nějak komprimovaný) nebo aspoň mapu sektorů které jsou ne/nulové a nebo by udělal obraz jako sérii souborů po gigabajtech do složky (10000 není moc) přičemž by se buď každý file komprimoval samostatně a nebo nulové /prázdné bloky by se logicky nezapisovaly.

Spíš mi jde o nasměrovanání a nějakou generální radu, co je nejlepší přístup, ale rovnou vysypat sem mocný příkaz který přesně něco takového udělá taky ocením...

327

Sítě / Re:Pár dotazů k síti - 169.254 a rp_filter pro odchozí a příchozí

« kdy: 29. 11. 2021, 17:02:39 »

Kde vidíš že scope má link ? Já když se podívám narůzné systémy a vypíšu

Kód: [Vybrat]

ip route .... >scope link
ip address ... >global

tak mi to píše podivné výsledky (třeba to jsou dvě různé věci) - jedno píše u všeho scope global , druhé scope link, mám pocit  jako kdyby to nebylo správně

328

Sítě / Pár dotazů k síti - 169.254 a rp_filter pro odchozí a příchozí

« kdy: 29. 11. 2021, 01:05:33 »

Snažím se pochopit  nakonfigurovat firewall a jedna věc by mě zajímala, myslím, že není zrovna triviální. Na komplu je zapnuto ipv4.ip_forward, má 2 rozhraní(typicky eth - vniřní síť, wan =tam kde je gateway). Možná tu budu míchat víc věcí najednou.

1. : Jak je ošetřeno, aby pakety 169.254. neprocházely mezi sítěmi? Stačí na to (automaticky existující-proč?) záznam v route: 169.254.0.0     0.0.0.0         255.255.0.0     U     202    0        0 eth Kompl má tedy na eth mimo své i link-local adresu z nějakého důvodu (ip address - Má scope global, jestli to k něčemu). Ale chci aby tofungovalo nezávisle na tom ,jestli LL adresu má a zda je v seznam rout.  Nebo ví nějak linux "shůry" že 169.254 nemá routovat ?

2. : Pokud dám net.ipv4.conf.<XXX>.rp_filter = 1 (kromě toho, jestli to nějak vyřeší bod 1.), tak hraje roli, jestli to nastavím (XXX) jen pro wan jen pro eth nebo pro all (stejné jako pro wan a eth ). Bude to mít vliv na "směr ochrany"? (z wanu src=lokální , z wanu cíl nelokální, z Lanu src nelokální, z Lanu cíl ne-internet). Předem se omlouvám za takovéhle zjednodušení. Má smysl mít rp_filtr vůbec, jen na jednom (jen eth, jen wan) rozhraní nebo až teprv na obou?


3. a když se zeptám "hloupě" (vlastně tím generalizuju dotaz), musí na všechno být pravidla do iptables, nebo se i některé věci jako výše dají řešit "na správnějším místě" - definice route, definice adresního rozsahu na rozhraní, definice scope(pokud to má nějaký praktický význam), rp_filter ?

329

Software / Re:Příkaz pro neukládání duplicit historie terminálu

« kdy: 24. 11. 2021, 23:24:13 »

Skvělé.    Právě se mi ztratil asi 10 minut psaný odeslaný příspěvek s zprávou Lituji, přistup odepřen, kdy po přihlášení v jiném tabu jsem doufal, že stačí dát Reload. Vypadalo to tak... Prohlížeč se zeptal Resend POST data? Ale hláška fóra řekla NE. Neodeslali jste tento příspěvek dvakrát? NE!!! Neuložil  se vůbec! Ačkoliv technicky se musel odeslat.

Poslední šance Tlačítko zpět... Prázdný formulář...

Nevíte proč mi nefunguje tato konfigurace .bashrc? Záměr je aby se historie neukládaly duplicity a to v další session. A zároveň any zůstávaly předchozí zadané píkazy (což je běžná situace). Prostě aby historie bobtnala, ale ne o duplicity

Kód: [Vybrat]

export HISTCONTROL=ignoreboth:erasedups

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash$
export HISTSIZE=10000
export HISTFILESIZE=20000

Hádám, že chyba bude někde v módu histappend. Jenže z těch voleb a threadů které to rozebírají na stackoveflow mi jde hlava kolem.


Konkrétní příklad (pro stručnost odděleno mezerami aby to nezabíralo tolik řádků tadz

Kód: [Vybrat]

*nová session
ls pwd ls pwd uname
*ukončení
*nová session
ls pwd ls pwd 
*ukončení
*nová session
<šipka nahoru dává: pwd ls uname ls pwd
ls 

Takže se duplicity neukládjí ale jen v rámci jedné session, to mi ale nestačí.


Další mé "požadavky"
- není nutné ani žádoucí,aby se soubor s historií zapisoval po každém příkazu (stačí po ukončení sezení)
- v případě více souběžných session aby po jejich postupném ukončení se zohlednila historie ze všech (ne aby poslední ukončený pes přemrdal historii)
- není potřeba už aktivně promazávat duplicity v existujícím souboru s historií. To mohu udělat jednorázově až budu mít funkční konfiguraci.
-Ale kdyby existovalo něco jako history --prune nebo --remove-dups, nepohrnul bych

330

Server / Více teček v mailové adrese za @

« kdy: 24. 11. 2021, 22:45:52 »

Je možné aby emailová adresa mihla mít část za @ z víc částí oddělených tečkami? Třeba @bond.firma.cz

Má zo nějaké seciální vlastnosti , výhody a použití? Jak se k tomu přistupuje z hlediska SMTP(a dalších) serverů? Jako jestli jde o kompletně izolované domény nezávislé nebo tam.funguje nějaká delegace.