Poslední příspěvky

1

Software / Re:Velmi pomalý grep -P oproti grep -E

« Poslední příspěvek od mikesznovu kdy Dnes v 16:21:11 »

Problém se mi zredukoval na to, že -P je pomalejší než -E... Nakonec jsem přišel i na jednogrepovou pipeline |grep -Ezo ":\"https://.[^/]+" .  Doba trvání je 2s cpu času mínus 1.6 na download ,což už jde (bohužel time měří i download a nechce se mi to ukládat, zatímco v bashi 5.1 jde příkaz time za pípu tak v 5.0 to nejde a curl zahlásí failed to) ...

Ale zarazilo mě, že to -P je šíleně pomalé.



Jo, \K je syntaktický sugar, navíc v -E nefunguje.
pps://.+?/ je  "aspoň 1 znak, požrat minimum, co je možné" narozdíl od varianty bez "?",  to je greddy/ungreedy operátor(modifikátor?), tím pádem by tam šlo i použít ttps://.*?/,  protože doména má minimálně 7 znaků (snad to není Jirsák trigger)

Ale důležité je to lomítko za ,aby to kde to má skončit.  takže ps://.*?/ je stejné jako ps://[^/]+/

2

Server / Re:Certifikáty na souborovém systému jen ke čtení

« Poslední příspěvek od alex6bbc kdy Dnes v 16:04:13 »

Ak začínam správne chápať, tak Let's Encrypt je CA najvyššej úrovne, t.j. ten ISRG, ktorý ma Expiration Date v roku 2035, patrí Let's Encrypt?

Tomuto celkom nerozumiem:

Pokud je víc alternativních certifikačních cest (což je třeba případ výměny kořenového certifikátu), je možnost při vydávání certifikátu si zvolit, která cesta se má použít.

Znamená to, že už pri vydávaní certifikátu má certifikát zapísaných viacero alternatív k (PKI) rodičovským certifikátom?

Ak som správne pochopil, tak Let's Encrypt vydáva certifikáty na krátke obdobie (niekoľko mesiacov, alebo pár rokov), takže ak pôjdem cestou certifikačnej autority, tak vidím skôr riešenie v manažovaní tých koreňových trusted certifikátov pre klienta a to tak, že bude treba vystihnúť dobu, počas ktorej sa budú musieť certifikáty na všetkých embedded zariadeniach updatovať.

V prípade, že si sám podpíšem certifikát, tak si musím update manažovať tiež sám. Poprípade nebudem updatovať certifikát vôbec, čím viac riskujem zvýšenú možnosť kompromitácie po nejakom čase...

letsencrypt nemusi byt top level, ale jeho certifikaty co certifikuji nizsi urovne jsou certifikovane top certifikaty, takze se letsencrypt certifikatum veri.

muzete si sam delat certifikaty pomoci nastroje openssl, ale pak si je musite rucne datna server, do prohlizece a treba i do systemu.

3

Server / Re:Certifikáty na souborovém systému jen ke čtení

« Poslední příspěvek od majvan kdy Dnes v 15:59:05 »

Ak začínam správne chápať, tak Let's Encrypt je CA najvyššej úrovne, t.j. ten ISRG, ktorý ma Expiration Date v roku 2035, patrí Let's Encrypt?

Tomuto celkom nerozumiem:

Pokud je víc alternativních certifikačních cest (což je třeba případ výměny kořenového certifikátu), je možnost při vydávání certifikátu si zvolit, která cesta se má použít.

Znamená to, že už pri vydávaní certifikátu má certifikát zapísaných viacero alternatív k (PKI) rodičovským certifikátom?

Ak som správne pochopil, tak Let's Encrypt vydáva certifikáty na krátke obdobie (niekoľko mesiacov, alebo pár rokov), takže ak pôjdem cestou certifikačnej autority, tak vidím skôr riešenie v manažovaní tých koreňových trusted certifikátov pre klienta a to tak, že bude treba vystihnúť dobu, počas ktorej sa budú musieť certifikáty na všetkých embedded zariadeniach updatovať.

V prípade, že si sám podpíšem certifikát, tak si musím update manažovať tiež sám. Poprípade nebudem updatovať certifikát vôbec, čím viac riskujem zvýšenú možnosť kompromitácie po nejakom čase...

4

Sítě / Re:Výběr síťových prvků

« Poslední příspěvek od MrWhite69 kdy Dnes v 15:58:23 »

Co se týče bezpečnosti, tak veškerá data jsou v cloudu u 3. stran, nic není uloženo na fyzickém úložišti v ordinacích.

No tak to potěš koště.

Ehm delal jsi nekdy v korporatu? Hadej kde ty maji ulozena data.
Znameni dnesni doby, az naroste zase pocet hacku cloudu, vrati se vsichni na on-premise

5

Software / Re:VP9 do HEVC bez komprese pomocí FFMpeg

« Poslední příspěvek od Jigdo kdy Dnes v 14:53:17 »

Diky vsem za prispevky.

Specificke parametry pro "hevc_nvenc" jsem zkoumal,
ale je jich tam tolik, ze mi vetsina nic nerika

Mne jde hlavne o to, ze chci "video" z VP9 do HEVC pokud mozno ve kvalite "1:1"
(to video ma jen 5 min a ve VP9 cca 493.5 M) - aby HEVC nesnizil pri te
konverzi "Bit rate".....a myslel jsem ze FFMpeg pokud neuvedu "-b:v"
provede 1:1 konverzi ..... kvalita nad velikosti...


VP9 original ma 13.4 Mb/s, takze pro jistotu volim 14 Mb/s u "-b:v"
a vysledek vypada na pohled stejne jako ve VP9

Kód: [Vybrat]

ffmpeg -hide_banner \
-y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda \
-i Global.weather.2024-April-June.f625+140.[DAW-GpnJIgE].mp4 \
-map 0:0 -map 0:1 -map 0:2 \
-c:V:0 hevc_nvenc -b:v 14M \
-c:v:1 copy \
-c:a copy \
-c:s copy \
-c:d copy \
-map_metadata 0 \
-f mp4 -movflags +faststart \
-copy_unknown \
Global.weather.2024-April-June.HEVC-B-V-14+140.[DAW-GpnJIgE].mp4 -v verbose


Jeste jsem zkousel "-b:v 0" - range je [0 - 9.22337e+18]
a vysledne video je o velikosti 704.8 M a "Bit rate" 19.2 Mb/s

Kód: [Vybrat]

ffmpeg -hide_banner \
-y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda \
-i Global.weather.2024-April-June.f625+140.[DAW-GpnJIgE].mp4 \
-strict experimental \
-map 0:0 -map 0:1 -map 0:2 \
-c:V:0 hevc_nvenc -b:v 0 \
-c:v:1 copy \
-c:a copy \
-c:s copy \
-c:d copy \
-map_metadata 0 \
-f mp4 -movflags +faststart \
-copy_unknown \
Global.weather.2024-April-June.HEVC-B-V-0+140.[DAW-GpnJIgE].mp4 -v verbose

6

Sítě / Re:Vodafone chce výměnu modemu pro dual-stack

« Poslední příspěvek od petrisdiver kdy Dnes v 14:48:29 »

Mne za cca 14 dnu. Chci ted behem par dnu zvazit T-Mobile, ketry je zde pritomen taky. Mel bych vic nez 2x vetsi upload a lepsi latenci, ale zatim to nevypada s bridge rezimem. Uvidime.

Ceka mne neco podobnyho. Zjistoval jsem u T-M jak to je s jejich modemem, ze bych misto neho chtel SFP+ modul. Marna snaha , jediny co jsem se dozvedel je ze se mne nekdo ozve az prijdu na radu

7

Desktop / Re:Proč mi zabiják OOM zabil Chromium

« Poslední příspěvek od anonacct kdy Dnes v 14:44:05 »

2GB RAM?

Prosím tě, udělej něco pro ostatní a upgraduj. Ten čas cos spálil ostatním už teď je dražší než cena toho upgrade. Vždyť lidi vyhazujou i lepši sestavy do šrotu...

8

Server / Re:Certifikáty na souborovém systému jen ke čtení

« Poslední příspěvek od Filip Jirsák kdy Dnes v 13:56:23 »

Aka dlha byva tato doba? Je nejaky mechanizmus na query "je novy certifikat", alebo v sucasnosti sa spolieha na to, ze pocas tejto doby prebehne update, ktory ten novy certifikat ziska?

Obvykle je to několik měsíců, i přes rok. Ale ono je to dost různé, protože často je ta změna kořenového certifikátu důsledkem jiných změn.

Pokud je víc alternativních certifikačních cest (což je třeba případ výměny kořenového certifikátu), je možnost při vydávání certifikátu si zvolit, která cesta se má použít. Takže ty informace jsou dostupné přes API. A Let's Encrypt o tom také dopředu informuje, takže je dobré sledovat třeba jejich blog.

9

Server / Re:Certifikáty na souborovém systému jen ke čtení

« Poslední příspěvek od Filip Jirsák kdy Dnes v 13:48:50 »

Aktualne maju RSA root do 2030-06-04

To mají napsané v textu, nicméně ve skutečnosti je i ten RSA root vydaný s platností do 2035-06-04.

Moznost vlastnych certifikatov (ako pisu Petr Krcmar a Filip Jirsak vyssie) nastupuje az v pripade, ak zavrhnes povodnu ideu fungovat pod Let's Encrypt, pripadne budes chciet mat nejaku vlastnu zalohu napr. pre pripad ze LE skonci.

Nikoli, i DANE nebo používání stále stejného klíče je možné použít s certifikáty od Let's Encrypt. Ten HTTPS klient v zařízeních by sice používal DANE nebo by měl v sobě několik klíčů a bylo by mu jedno, že jsou ty certifikáty vystavené pomocí LE. Ale server by měl normálně uznávané certifikáty, takže kdyby se k serveru připojil někdo běžným webovým prohlížečem (třeba proto, že by ten server poskytoval i nějaké webové rozhraní), dostal by klasický certifikát od LE.

Na bezpecne fungovanie ale na klientovi tiez potrebujes to iste - nejake ulozisko certifikatov, kde vies novy certifikat pridat a stary zmazat.

Není to potřeba, pokud si budete věřit, že nedojde ke kompromitaci privátního klíče.

Tohle už se řeší snadno, do toho klienta se dá víc veřejných klíčů, kterým věří. Jeden soukromý klíč se pak nasadí na server a ostatní se nechají bezpečně v záloze. Když něco selže, vyndá se jeden ze záložních klíčů a jede se dál.

To je dobré řešení, ale pak je potřeba mít zajištěné, aby nemohlo dojít ke kompromitaci privátního klíče, tj. mít privátní klíč v HSM nebo aspoň nějakém USB tokenu.

10

Software / Re:Brutálně pomalý grep (3MB) 3000 výskytů ... pomalý asi 5Hz jen do konzole

« Poslední příspěvek od Vít Šesták (v6ak) kdy Dnes v 13:45:10 »

Perl regex (-P) a extended regex (-E) jsou dvě různé implementace, rychlost je může dost lišit. A mají trochu jinou syntax. Mimochodem, -P -z je experimentální kombinace.

Co má být ".+?"? Nemá to být ".*"? (Z hlavy nevím priority.)

Bez -K se lze obejít použitím nástroje sed. Buď následně odstranit všechna http:// ze začátku řádku, případně se na greo vykašlat úplně a řešit to jen sedem.