Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Honza1Ubuntu

Stran: [1] 2 3 ... 14
1
Distribuce / Re:Je bezpečná zamčená obrazovka v Ubuntu?
« kdy: 13. 10. 2021, 21:57:19 »
okias

Cold boot attack by mohl byt proveden, nebot do pameti se ukladaji klicove informace nesifrovane (pristupove klice). Tusim, ze neco takovyho dela napr. policie, kdyz jde po vytipovane osobe s PC, vyhlidnou si dobu kdy system bezi. Uz musi skutecke o neco jit.

Starý Tux, aaa158, Ondrej Nemecek

Tak to je v takovem pripade bezpecnost celkem nic moc, to se tam snad dostane kdejaky utocnik jouda. Do soukromych a pracovnich veci mi nikdo lezt nemusi. Jestli se na chvilku obrazovka obevi, urcite to neni idealni. Ale primo v popredi zneuzitelna data nechavat neni dobry napad. Horsi by bylo, kdyzby se utocnik primo mohl prihlasit (odemknout sezeni). Ale i to, ze se na zlomek sekundy obrazovka obevi, neni idealni.

k3dAR

Mam Ubuntu 16.04, protoze novejsi verze na notasu blbly. Tam jde jeste sifrovat jen home slozku. Coz neni nejsilnejsi bezpecnost (v tmp, swap a pod. muze neco byt), ale proti beznym utocnikum  (napr. v pripade kradeze notasu) to snad staci. Ve ve swapu, tmp, var, log se snazim nic duleziteho nenechavat. Idealni to ale urcite neni. Navic muze nekdo pridat neco na disk do systemu mimo home, co bude sbirat dalsi pristupove udaje. Staci se zmocnit vypnuteho notasu, ktery pak dal budu pouzivat.

2
Samozrejme, ze laser, ktery by dokazal na jakoukoliv vzdalenost (i tu nejmensi) zabit komara, nesezenes. Nejspis ani na darknetu za BTC. Neco takoveho navic bude extreme drahe a to jak porizovaci, tak provozni naklady (nejspis vic nez Bugatti Chyron).

Jakoukoliv radu ale stejne dat nemohu, nebot bych napomahal k trestnemu cinu vrazdy, coz samozrejme nechci. A to i prez to, ze komari jsou pekny svine a maji toho na svedomi vic nez dost a komary nesnasim.

U nas v CR ale nejlepe doporucuji si proste pockat, az ztrati silu sami od sebe. Oni totiz komarum postupne volici vymiraji. Sve na tom udelal i COVID vzhledem k ovyklemu veku volicu komaru. Poprve jsou mimo snemovnu, a to je dostacujici uspech zatim.

3
Distribuce / Je bezpečná zamčená obrazovka v Ubuntu?
« kdy: 11. 10. 2021, 22:08:01 »
Zdravim

Nejsem si jisty, jak moc je proti vnejsim zivlum dostatecne-bezpecne zamknout obrazovku v Ubuntu, za predpokladu, ze zustanu prihlaseny a vsechny moje spustene aplikace, prihlasena sezeni, budou aktivni (napr. mail, internetove bankovnictvi, prihlaseni prez terminal na jiny server).

Uzivatelske heslo mam dostatecke silne (nejde uhadnout BF ani nahodou) a domovska slozka v Ubuntu je sifrovana.

Jde mi o to, jak moc je bezpecne samotne zamceni obrazovky.

4
At jsem ruzne zkousel na testovacich datech, vypada to, ze nefunguje navrhovana verze:

Kód: [Vybrat]
for i in `sha256sum ./* | awk '{ print $1}'  | uniq -d -w64 `; do  rm -vf `sha256sum ./* | uniq -Dw64 | grep $i | tail +2 | awk '{print $2}'` ;done

Zkousel jsem ruzna testovaci data, ve slozce s 20 soubory bylo nekolik souboru se stejnym obsahem, ale jinym jmenem, jmena souboru jen z alfa-numerickych znaku. Po spusteni nekolikrat zadny ze souboru smazan nebyl.

Urcite tam ma byt tail +2 ? U nekterych souboru to haze chybu:

Kód: [Vybrat]
tail: cannot open '+2' for reading: No such file or directory

A vypada to, ze chybu hodi tolikrat. kolik je tam ruznych obsahu v mnozine duplicitnich souboru, nehlede na celkovy pocet duplicitnich souboru. tail -2 vybere 2 posledni radky z vyctu, ale tail +2 ? Na textovy soubor mi tail +2 nefunguje, tail -2 vypise posledni dva radky. Verze s tail -2 vymaze nektere duplicitni soubory, ale ne vsechny.

I kdyz se mi puvodne navrzeny kod nepodarilo zprovoznit, snazil jsem se jednotlive veci pochopit a nejak vymyslet vlastni prikaz. Cimz samozrejme dekuji za naznak reseni. A toto je muj vysledek:

Kód: [Vybrat]
for X in `sha256sum ./*  | sort -r | uniq -d -w64 | cut -d "/" -f 2` ; do echo "Mazu duplicitni soubor ${X}" ; rm ${X} ; done

Kod, ktery jsem navrhnul, tak v pripade souboru se stejnym hashem ale jinymi jmeny, vypise abecedne posledni jmeno z listu souborutotozneho obsahu (jinych jmen jinym jmenem), a ten soubor smaze. Od kazde skupiny duplicitnich souboru s unikatnim hashem smaze ten soubor abecedne posledni.

Takze kdyz ma stejny hash-obsah vic nez dva soubory, tak se ten prikaz musi spoustet vicekrat, a to tak dlouho, dokud skript hlasi, ze neco maze (maze jen abecedne posledni soubor). Neprakticke, ale zatim neodladeno. Kdyz skript nic nehlasi-nemaze, tak uz se duplicitni hash nevyskytuje, kazdy hash je unikatni.

Podminkou pro fungovani meho skriptu ale jsou slusne nazvy souboru (bez mezer ci specialnich znaku), jinak si nejsem jisty, co to udela, tak s obecnym pouzitim pozor. V pripade adresaru sha256sum zahlasi, ze hash nepocita - sha256sum: ./Test: Is a directory. A do adresaru se skript nekouka, maze duplicitni soubory jen v danem adresari a v dane urovni podle vseho (ne soubor v adresari a jeho duplicita v podadresari).

5
snuff1987

Diky moc, to vypada rozume, snazim se porozumet vsem tem parametrum.

Citace
for i in `sha256sum ./* | awk '{ print $1}'  | uniq -d -w64 `; do  rm -vf `sha256sum ./* | uniq -Dw64 | grep $i | tail +2 | awk '{print $2}'` ;done

 ;D ::)

Neni takto napsany kod pro uplne cely disk (tj. provede akci na uplne celem souborovem systemu, tedy /* ?). Se bojim spustit, aby to nezasahlo cely disk. Vlastne ne, spatne porozumeni kodu, ./* vypada, ze se spusti jen v aktualni slozce.

Soubory nejsou extreme velke, a pocet souboru je v radu nekolika tisicu, vetsinou 2000-15000, vyjimecne vice. Velikost souboru je radove stovky kB, obcas prez 1 MB. Tak by samotne pocitani hashu 2x nebyl takovy problem.

Specialnim nazvum v souborech se snazim vyhnout, celkem se mi to dari redukovat na podtrzitko a alfa-numericke znaky. Ale obcas se mezera, nebo -( a podobne vyskytne. Ale zredukovani tak, aby tam tyto znaky nebyly (jeden z cilu) se mi relativne dari, mozna jeste potreba doladit.

6
Zdravim

Nemuzu prijit na jednu vec. Mam ve slozce radove nekolik tisic souboru (vsechny soubory v jednom adresari, zadne podadresare) a nektere soubory jsou vice-nasobne tim zpusobem, ze se vyskytuje soubor s uplne stejnym obsahem nekolikrat v teto slozce, jenze pod jinymi jmeny a i datum posledni zmeny muze byt jiny (napr. totozny z datumem stazeni). Kdyz je soubor se stejnym obsahem jen pod jinym jmenem, tak by mel byt stejny kontrolni soucet, pokud je ale krome jmena jiny i datum, uz si tim nejsem jisty.

Mel by nekdo napad, jak v terminalu promazat vice-nasobne soubory (stejny obsah, ruzna jmena) a ponechat jen jeden soubor (soubor se jmenem, ktere je podle abecedniho razeni vice-nasobnych souboru na prvnim miste) ?

7
Wrána diskuze

Presne takle ne, jen tak nejake cislo (ktere k nicemu nepatri) zapsat. Navic se to da zapsat i elegantneji. Napr slovem gogolplex. Ale i tato hodnota bude prekonana.

Ondřej Vaniš a Kit

Pocet baryonu v pozorovatelne casti vesmiru je rekneme plus minus okolo 10^80, ale Planckova delka, to je vpodstate neco jako zakladni jednotka prostoru, nejmensi mozna delka. Odtud vychazeji i dalsi nejvyssi-nejnizsi mozne hodnoty velicin. V pozorovatelne casti vesmiru je kosticek o Planckove delke odhadem rekneme tech 10^184.

Z Planckovy konstanty h, gravitacni konstanty G, a rychlosti svetla ve vakuu c jde snadno udelat jednotky - jsou to limity vsech fyzikalnich velicin. Planckuv cas, tech cca 5.10^-44 je doba, za kterou svetlo prekroci Planckovu delku, tedy Planckuv cas. Nejmensi mozna cerna dira o rozmeru PLanckovy delky a s PLanskovou hmotnosti se vypari za Planckuv cas, a ma Planckovu hustotu (=nejvyssi mozna hustota), stejna hustota by mela byt ve stredu cernych der a kdyz byl vesmir stary prave Planckuv cas. A hustota je radove 10^97 kg/m3. Je-li hmota v pozorovatelne casti vesmiru rekneme 10^54 kg, s tim ze rad (10^kolik je nejisty), tak by vsechna hmota pri Planckove hustote zabirala jen nekolik femtometru, (jednotky radu 10^-15, cca velikost atomoveho jadra).

Planckovy jednotky:
https://en.wikipedia.org/wiki/Planck_units
https://astronomy.swin.edu.au/cosmos/P/Planck+Units

ondrej12345
Klic nebo heslo ze 100 znaku (obecne z n znaku), to je pri pouziti alfa-numerickych znaku 62^100 resp. 62^n. Alfa-numerickych znaku je 62. Pripouziti dalsich znaku to nebude 62, ale vyssi cislo. Avsak mnozstvi znaku je maximalne 256, pri 8-bit kodovani, 65536 pak pri 16-bit kodovani. Takze je pocet kombinaci maximalne 256^100, tedy 2^800, pri 16-bit kodovani znaku je u 100-znakoveho nesla ci klice kombinaci 65536^100, tedy 2^1600. Misto 100 se da nosadit n pro n-dlouhe heslo ci klic. Problem je ale, jake je sifrovani, je li 256-bitove (AES256),pak je maximalni pocet variant 2^256, atd.

jardaplc
Pocet variant obrazku, (nebo pocet moznych obrazu na monitoru), to je velke cislo dost, obecne je pocet moznych obrazku 2^[(barevna hloubka v bitech)*(sirka)*(vyska)]. Takze uz jen png s 8-bit hloubkou a rozlisenim 1024x768 ma variant 2^6291456, coz je o neco mene nez 10^1893917. A co teprve pocet variant filmu, to je 2^(24*sirka*vyska*celkovy pocet snimku). A s tim souvisejici mnozstvi ruznych obrazu disket, CD, HDD. Obecne mnostvi variant souboru velkeho X bajtu je 2^(8*X). Ale ani vsechna data na Zemi nepresahla zatim 10^30 B, mnozstvi variant je tedy mensi nez 2^10^30.

P_V

To jsou asi nejvetsi cisla ktera se ve fyzice, i jinych vedach daji najit. Ani teorecicke mnozstvi kombinaci vsech dat na Zemi (mensi nez 2^10^30) nedosahuje takovych hodnot. Odhady opravdu daleke budoucnosti vesmiru jsou na zaklade znalosti z kvantove fyziky a pravdepodobnosti-statistiky, s predpokladem, ze znalosti jsou zcela spravne a je mozne stejne principy interpolovat nekonecne daleko. Jako fyzik velke casti odhadu rozumim, resp. vim o co tam jde a na zaklade ceho k tomuto odhadu dosly. Ale interpolovat tak daleko, s tim ze porad budou platit stejne principy, to nejspis bude spatne. Tem uplne nejvetsim hodnotam casu na konci moc nerozumim, o co tam jde, jak k tomu dosli. Tak jako tak je to nepredstavitelna casova hodnota.
 

8
Bazar / Re:Prodám ThinkPad T460
« kdy: 06. 07. 2021, 21:40:01 »
Bez parametru (velikost RAM, HDD, typ CPU, pocet jader) to nic moc nerika. Hlavne taky jestli je disk v dobrem stavu (zkontrolovat napr. badblocks -sv /dev/sdXY za XY je nutne samozreme dosadit). Window se da preinstalovat resp. nainstalovat Linux vedle a dual boot.

Stejne ale uz prodano, tak to nema cenu resit.

9
/dev/null / Jake vas napada co nejvetsi cislo resp udaj neceho
« kdy: 06. 07. 2021, 21:34:53 »
Mam tu takove odlehcucici tema, a to jaky vas napada udaj nejake veliciny s co nejvetsi ciselnou hodnotou. Udaj muze byt z fyziky, statistiky, ekonomiky, ci jine vedy. Musi se ale udaj k necemu vazat, tedy ne obycejny zapis nejakeho cisla, co se k nicemu nevaze.

Napriklad celo-svetovy obem dat muze byt odhadem 10-1000 tisic miliard GB resp. 10^22-25 B, nebo i vic.

Pocet baryonickych castic v pozorovatelnem vesmiru muze byt okolo 10^80.
Doba vypareni nejvetsi cerne diry (s predpokladem rustu) je 10^102-106 let resp. 10^109-114 s.

Urcite se najdou i o dost vyssi ciselne hodnoty u nekterych udaju.  Jen takove odlehcujici tema, co vas napadne.

10
Software / Re:Software pro skládání panoramat
« kdy: 03. 03. 2021, 17:01:17 »
Presne tohle jsem resil tusim 2-3 roky nazpet. Fotky jsem mel rucne nafocene, tak ze se postupne pokreje cela oblast. Jednotlive fotky se prekryvaji, ale pravidelna paralaxa, ci sklon tam neni.

Ve Windows jsem pouzival ICE panorama, jez pracuje tak, ze najde mezi jednotlivymi fotografiemi ruzne tvarove-barevne shody (i pri nepravidelnosti fotek a ruzne jdouci fotky za sebou). Panorama vytvri celkem dobre a je to freeware. Ale musi byt na Windos nainstalovana urcita knihovna.

V Ubuntu jsem zkousel najit nejaky program, ktery by to zvladnul. Zkousel jsem Hugin, ale Hugin potrebuje nejakou pravidelnost ve fotkach (paralaxa, setrideni) a pri rucnim nafoceni se panorama vytvorit nepodarilo. Autopano jsem take zkousel, a take se to pri rucne nafocenem pokryti krajiny nepodarilo a na zadne reseni jsem zatim (ani po letech) neprisel.

Vim, ze Smartfouny taky umi panorama celkem dobre, maji na to nejaky vlastni program. Jenze smartfoun nepouzivam.

ICE Panorama od Microsoftu  nejde pod Linuxem samozrejme. A i pri instalace do Windows jsou obcas problemy, taky mi to neslo. ICE Panorama dava dobre vysledky, ale je to narocny na system.

Samotny proces nesmi prekrocit 2 GB Ram, me to zvladalo okolo 200-250 15 Mpix fotek maximalne pro vytvoreni jedne panoramy. I JPG ma svuj limit na maximalni sirku-delku obrazku (tusim okolo 86000 pixelu), a jak JPG tak PNG ma limitni pocet MPIX (aby sirka X vyska X barevna hloubka neprekrocila 2 GB, resp. rozliseni obrazku okolo 400 MPIX ?). Po prekroceni tohoto limitu je mozno panorama ulozit pouze ve specialnim ICE formatu. Proces take zere docela misto na disku v prubehu procesu. Cca 10 fotek po 15 Mpix zabere 500 MB v prubehu procesu, na konci se to uvolni.

I na CPU je tvoreni panoramat narocne (bez ohledu na program). ICE Panorama s jednim vlaknem na I7 - zpracovat okolo 100 15Mpix fotex trva minuty, 200 fotek po 15 Mpix pak okolo 30 minut, 20 fotek trva jen par vterin. Zavislost je cca kvadratocka (CPU cas=Pocet fotek na druhou).


Promin, ze ti neumim poradit, sam jsem na reseni take neprisel.

Predchozi tema:
https://forum.root.cz/index.php?topic=18782.0

11
Pred vypnutim notebooku probihala aktualizace Ubuntu, bezici automaticky po odkliknuti. Avsak v prubehu aktualizace vypadl proud a baterka na notebooku nebyla nabita, tak se v prubehu procesu notas natvrdo vypnul.

Na notasu jsou dva systemy a dva partition - Windows a Ubuntu. Ubuntu ted, po vypnuti uprostred aktualizace, nejde zapnout (nenabehne system), Windows nabehne normalne.

Ma smysl pokusit se nejak spravit instalaci Ubuntu, nebo je lepsi preinstalovat celou partition ?

V home Ubuntu nejaka uzivatelska data jsou. Napada me - nabootovat Ubuntu s USB klice, pretahnout data s home Ubuntu do Win partition, preinstalovat a v novem Ubuntu si data pretahnout zpet.

Pretahnutim do Win a zpet se smazou prava a vse bude 777. To bych mohl vyresit vytvorenim TAR archivu a popripade TAR archiv jeste zabalit (7zip nebo gzip).

12
arrange

... A jestli kontrolouje i spravnost zapisu na disk v cili pri kazdem behu, to tu resime.
Urcite nekontroluje bez -c kontrolni soucty zdroj-cil u souboru, ktere se neprenasi - jmeno a timestamp zdroj-cil souhlasi, tak se ty soubory neresi. Ale jestli kontroluje spravnost zapisu na disk prenasenych souboru ? Urcite kontroluje spravnost prenosu po siti. Kontrolni soucty pak by mel kontrolovat nejmene sam proces zapisu na HDD.

Az takhle jo, to se ti fakt menil obsah souboru, to velke zmeny, nebo jen zmeny par bajtu ?

Ja pouzivam klasicky HDD na notasu, popr. extreni HDD. Zatim se mi to nikdy nestalo - zmena dat bez toho, aby to hodilo chybu cteni-zapisu. Kdyz se zacal podelavat disk a byla chyba cteni-zapisu, tak se to cele hodilo do read-only, nebo proste soubor nejde precist. Zatim jsem nezazil ODHALENOU zmenu dat na HDD. U archivu napriklad i mala zmena odrovna cely archiv, u textu, obrazku, videa malou zmenu nepoznas. Zmenu bit jen jednoho bajtu ve skriptu nemusime rozebirat, muze udelat paseku:

Kód: [Vybrat]
cd ${cesta}
rm -fr *

nebo

Kód: [Vybrat]
cd ${cista}
rm -fr *

HDD, SDD, USB klice by meli mit pri cteni-zapisu kontrolni soucty, ktere odhali vadny sektor a chybny zapis-cteni, tedy pozkozena data (data corrupt). Nechytnou ale vsechno, pri velkem mnozstvi dat se obcas bit-flip (zmena bajtu-bitu) obevi. Snad jednou za X stovek GB jsem nasel. SD karty snad ani tyto kontrolni soucty nemaji (nebo jiny mechanizmus nemaji), nebo jsou ty kontrolni soucty maji SD karty slabsi bych spis rekl. To uz je ale mimo rsync.

Verze s -c ochrani-odhali spatne soubory v cili (podelany disk), bez -c neprenese podelane soubory ve zdroji a v cili zustanou spravne. Ale Pri vadnem sektoru by se mela ozvat chybn hlaska ze nejde cist-zapisovat, pri chybnem zapisu se disk hodni do read-only a stop. NE zapsat jina data.

13
Arrange

O to prave jde, spravnost prenosu po siti se resi vzdy pomoci kontrolnich souctu. At uz s -c nebo bez. Ale to tu prave resime, jestli je kontrolovano, zdali jsou spravne i soubory zapsany v cili (spravny zapis na disk, vadne sektory).

Na druhou stranu volba s -c muze prenest poskozeny soubor ze zdroje a prepsat v cili OK soubor, pokud je vadny sektor ve zdroji.

O chybnem zapisu na disk (zmena dat) se tu uz tusim diskutovalo, jestli se to muze stat. S tim ze by to nehlasilo chybu disku a precetl by se ve zdroji nebo zapsal v cili oubor chybne. Otazka je, jak casto, snad se pocita jedna zmena bitu (bit-flip) za X TB nebo dokonce X PB tusim. S urcitou, byt malou pravdepodobnosti se to muze stat jak ve zdroji tak v cili, tak ani spustit po druhe rsync s -c neni stoprocentni.

Pokud v cili nejde neco prepsat-zmenit (zmenit casy, prava, prepsat soubory), protoze napr. uzivatel nema opravneni, tak to rsync hlasi - ze nejde synchronizovat  kompletne a vypise chybu. A jestli kontrolouje i spravnost zapisu na disk v cili pri kazdem behu, to tu resime.


[...]Takze -c odhali soubory s jinym checksumem (tedy i obsahem, byt nepatrne odlisnym), ale se zaludne stejnou casovou znamkou, jmenem i umistenim (jak se neco takoveho stane ?)
napr. tak:
Kód: [Vybrat]
cp -a soubor soubor.bak
echo "neco" >>soubor
touch -r soubor.bak soubor

Presne tak

Jestli je soubor nepatrne, nebo kompletne odlisny, to uz se neresi, checksumy by se mely lisit prakticky vzdy, i pri nepatrne zmene (neni to uplne pravda, ale pravdepodobnost odlisnych souboru se stejnym checksumem je naprosto minimalni).

Pri beznem provozu, praci a zalohovani me nenapadlo, jak by se to mohlo stat.  Ale pokud nekdo bude ve zdroji nebo cili delat nepravosti a umyslne skodit, tak to mozne je. Nedopatrenim se to taky muze stat pri zpracovani dat, ale ne uplne snadno.


14
Software / Re:Rozpadající se weby při blokování JS
« kdy: 02. 09. 2020, 22:46:37 »
Tech 20 JS skriptu na nekterych strankach a reklamy - to je  dobre poznat, kdyz na takove strance jsem - zacne hucet vetrak. A i na RAM to poznas. Kdyz mas takovych stranek otevrenych vic, docela to zpomaluje komp. Bez JS zatizeni CPU minimalni.

Takze ne jen bezpecnost, ale vytizeni PC je duvod k blokaci. Nektere stranky ale bez JS nejdou.

15
Bez -c se může chybně vyhodnotit nutnost soubor přenášet. S -c se nutnost vyhodnotí na základě checksumu, takže je záruka, že se přenese vše, co se změnilo. Přenos a zápis do souboru se pak provede i s kontrolou konzistence. Takže při -c by nemělo být potřeba zadávat příkaz 2x. Tak tomu rozumím já.

Taky tomu rozumim tak, ze -c akorat vyhodnocuje pomoci kontrolnich souctu, zdali je nutne soubor prenaset. Bez -c se nutnost prenosu hodnoti podle toho, jestli se shoduje timestamp, jmeno a umisteni souboru. Takze -c odhali soubory s jinym checksumem (tedy i obsahem, byt nepatrne odlisnym), ale se zaludne stejnou casovou znamkou, jmenem i umistenim (jak se neco takoveho stane ?)

Ta kontrola konzistence zapisu v cili a prenosu po siti by snad mela podle vseho probehnout vzdy, nezavisle na -c, tak tomu rozumim.

2x rsync spoustet nejdriv bez -c a pak s -c by snad melo odhalit jen soubory zdanlive stejne (jmeno, cas, umisteni) ale s jinym checksumem. Stejne tak, pustim li rsync jen jednou s -c. Spousteni 2x (podruhe s -c) by odhalilo i chybny zapis s cili, ktery by nemel kvuli kontrole konzistence VZDY nastat.

Pokud je datovy soubor velky (stovky GB) a soubory, ktere se maji prenest jednotky GB, tak samotny prenos muze trvat minuty, kontrola checksumu na obou stranach i par hodin.

Stran: [1] 2 3 ... 14